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1  Introduction  and  Motivations 


P-PATR  is  a  compiler  for  unification-based  grammars  that  is  written  in  Quintus 
Prolog  running  on  a  Sun  2  workstation.  P-PATR  is  based  on  the  PATR-II'  for¬ 
malism  [14]  developed  at  SRI  InternationEd.  PATR  is  a  simple,  unification-based 
formalism  capable  of  encoding  a  wide  variety  of  grammars.  As  a  result  of  this 
versatility,  several  parsing  systems  and  development  environments  based  on  this 
formalism  have  been  implemented  [18,5].  P-PATR  is  one  such  system,  designed 
in  response  to  the  slow  parse  times  of  most  of  the  other  PATR  implementations. 

Most  of  the  currently  running  PATR  systems  operate  by  inierpreiing  a  PATR 
grammar.  P-PATR  differs  from  these  systems  by  compiling  the  grammar  into  a 
Prolog  definite-clause  grammar  (DCG)  [8]. 

The  compilation  is  done  only  once  for  a  given  grammar;  the  resulting  DCG 
contains  all  the  information  in  the  original  PATR  grammar  in  a  form  readily 
conducive  to  parsiiig.  The  advantage  of  compilation  is  that  less  work  needs  to 
be  done  during  parsing,  as  some  of  the  necessary  computations  have  already 
been  performed  in  the  compilation  phase. 

The  use  of  Prolog  as  the  target  language  of  the  compiler  b  advantageous  for 
two  reasons.  First,  like  PATR,  Prolog  uses  unification  as  its  method  of  opera¬ 
tion.  By  compiling  the  PATR  grammar  into  Prolog,  P-PATR  takes  advantage 
of  the  efficient  implementation  of  Prolog  unification.  Second,  the  performance 
of  the  resulting  DCG  can  be  improved  further  by  compiling  it  with  a  Prolog 
compiler. 

Thb  compilation,  combined  with  the  use  of  Prolog,  gives  P-PATR  a  speed 
advantage  over  the  other  currently  implemented  PATR  systems. 

The  rest  of  thb  paper  b  divided  into  three  parts.  The  first  section  dbcusses 
the  basic  algorithm  used  in  compiling  the  PATR  grammar  into  a  Prolog  DCG. 
The  second  section  consbts  of  a  detailed  description  of  the  actual  procedure 
followed  during  the  compilation.  The  appendix  contains  a  user’s  manual  for  the 
P-PATR  system  as  well  as  a  sample  grammar  and  some  selected  Prolog  code 
from  the  system. 


'  Henceforth  referred  to  simply  as  PATR. 
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2  Methods 


What  follows  is  a  detailed  explanation  of  the  techniques  used  in  compiling  a 
PATR  grammar  into  a  Prolog  DCG.  First,  an  explanation  of  the  general  mech¬ 
anisms  used  in  compiling  a  PATR  graiiunar  into  a  DCG  is  given.  This  com¬ 
pilation  scheme  is  then  refined  so  that  the  DCG  produced  is  equivalent  to  the 
original  PATR  grammar. 

2.1  Feature  Structures  as  Prolog  Terms 

In  Prolog,  unification  operates  on  terms,  not  on  PATR  feature  structures.  It  is 
therefore  necessary  to  model  PATR  feature  structures  as  Prolog  terms  to  take 
advzmtage  of  the  Prolog  unification  mechanism. 

Prolog  terms  differ  from  PATR  feature  structures  in  two  major  ways  [14]. 
First,  in  a  Prolog  term  a  value  is  identified  by  its  position,  while  PATR  feature 
structures  identify  a  value  by  associating  it  with  an  attribute.  For  example,  the 
two  Prolog  terms 

head (agreement (number (plural) ,  person(third))) 
head(agreement(person(third) ,  number (plural))) 

do  not  unify.  Because  the  order  of  the  arguments  is  different,  number  (plural)  is 
matched  against  person(third)  and  the  unification  fails.  The  second  difference 
is  that  two  Prolog  terms  unify  only  if  they  have  the  same  number  of  arguments, 
whereas  two  PATR  feature  structures  may  unify  even  if  they  differ  in  the  nimiber 
of  features.  For  example,  the  two  terms 

(1)  head(agreement(number(plural) ,  person(third))) 

(2)  bead(agreement(number(plural))) 

do  not  unify  because  the  arities  do  not  match.  Thus,  in  representing  a  feature 
structure  as  a  Prolog  term,  each  structure  must  be  given  a  fixed  order  and  arity. 

There  are  two  methods  generally  used  in  modeling  feature  structures  as 
Prolog  terms.  They  will  be  referred  to  as  tailing  and  feature  precompilation. 

•  Tailing 

The  first  method  for  converting  feature  structures  to  Prolog  terms  involves 
the  use  of  tail  variables.  Each  feature  structure  is  encoded  as  a  Prolog  term 
of  the  form^ 

^Tbe  Prolog  list  notation  is  used  to  represent  a  list  with  an  uninstantiated  tail  variable  [3]. 


5 


[featurel:  valuel,  ...  ,  ieatureH:  valueN  \  T]  > 

where  an  uninstantiated  tail  variable  is  placed  at  the  end  of  the  list.  Then, 
as  this  structure  is  unified  with  new  structures,  the  features  in  the  new 
structure  are  reordered  in  accordance  with  the  features  seen  so  far,  and 
any  new  features  are  unified  with  the  tail  variable.  For  examplcj  feature 
structures  1  and  2  are  represented  as  the  Prolog  terms^ 


[head : 

[agreement: 

[number: 

person; 

plurail, 
third  1 

Tl]  1 

T2]  1 

T3] 

[head : 

[agreement : 

[number: 

plural 

1  T4] 

!  T5] 

1  T6] 

and  then,  when  unified,  person:  third  unifies  with  the  tail  variable  in 
the  agreement  list,  producing  the  new  Prolog  term 

[head:  [agreement:  [number:  plural, 

person:  third  |  Tl]  |  12]  |  T3] 


•  Feature  Precompilation 

Tlie  second  conversion  method  involves  a  preliminary  pass  through  the 
grammar  to  determine  the  arity  and  composition  of  all  complex  feature 
values.  On  the  second  pass,  every  attribute-value  pair  is  placed  in  the 
correct  position  ruid  order  with  respect  to  the  other  features.  If  a  feature 
is  missing  from  the  structure,  an  uninstantiated  variable  is  inserted  in 
its  place.  For  example,  from  feature  structures  1  and  2  the  following 
information  is  extracted 

head  can  be  followed  by  the  feature  agreement,  and 
agreement  can  be  followed  by  the  two  features, 
number  and  person,  in  that  order. 

These  feature  structures  are  converted  into  the  Prolog  terms^ 

[head:  [agreement:  [number:  plural., 

person:  third]]] 

[head:  [agreement:  [number:  plureJ., 

person:  XJ]], 

^This  is  not  quite  accurate.  Throughout  this  pi^er  feature  structures  are  represented  by 
labeling  the  values  with  the  attributes  they  represent,  but  only  the  values  of  the  attributes 
are  actually  present  in  the  feature  structures.  The  attributes  are  included  for  readabiLty  only. 
*  Variables  ate  distinguished  iiojn  atoms  by  an  initial  capital  letter. 
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where  the  missing  person  value  in  feature  structure  2  is  represented  by  the 
uninstantiated  variable  X.  The  two  Prolog  terms  now  unify  successfully 
to 


[head:  [agreement:  [number:  plural, 

person:  third]]] 

P-PATR  uses  the  feature  precompiiation  method  described  above  in  encod¬ 
ing  the  feature  structures  associated  with  the  PATR  grammar  entries  as  Prolog 
terms.  When  the  unification  list  of  a  rule  is  processed  during  compilation,  this 
feature  information  is  used  in  creating  the  feature  structures.  For  example, 
given  the  information  extracted  from  feature  structures  1  and  2,  the  unification 

<X  head  agreement  person>  =  <Y  head  agreement  person> 

produces  the  following  feature  structures  for  X  and  Y 

[head:  [agreement:  [person:  A,  number:  B]]] 

[head:  [agreement:  [person:  A,  number:  D]]] , 

where  the  values  of  the  person  attribute  are  unified  and  the  indeterminate 
values  for  number  are  added  to  complete  the  agreement  features. 

2.2  Basic  Compilation 

The  compilation  produces  a  DCG  that  has  a  one-to-one  correspondence  with 
the  original  PATR  grammar. 

•  GrammaT  Rules 

PATR  grammar  rules  consist  of  a  context-free  phrase  structure  (CFPS) 
rule  augmented  with  a  list  of  unifications.  For  example 

S  ^  HP  VP: 

<S  head>  =  <VP  bead> 

<VP  head  agreement>  =  <HP  head  agreement>. 

The  CFPS  part  of  the  rule  is 
S  HP  VP 
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and  the  unifications  give  the  added  information  that  the  agreement  fea¬ 
tures  of  the  VP  and  the  NP  must  be  the  same. 

DCGs  are  a  natural  extension  of  context-free  grammars  (CFG);  a  straight¬ 
forward  translation  scheme  is  given  by  Pereira  [7].  The  constituents  of  a 
DCG  rule  may  be  complex  symbols,  consisting  of  a  functor  and  a  list  of 
arguments.  In  the  translation  of  a  PATR  rule  to  a  DCG  rule,  the  CFPS 
part  of  the  rule  provides  the  functors  of  the  DCG  rule,  while  the  feature 
structure  information  from  the  unifications  is  encoded  as  the  arguments  to 
these  functors.  For  example,  the  grammar  rule  just  presented  is  equivalent 
to  the  DCG  rule® 

s([head:  fagreement:  Y]])  — > 

npCfhead:  [agreement:  Y^]), 

vpCChead;  [agreement:  Y33). 

•  Lexical  Entries 

PATR  lexical  entries  consist  of  a  word  followed  by  a  list  of  unifications. 
For  example 

Word  Uther : 

<cat>  =  HP 

<head  agreement  person>  =  third 
<head  agreement  nuiBber>  =  singular. 


This  entry  defines  the  word  “Uther”;  the  unifications  encode  the  informa¬ 
tion  that  “Uther”  is  a  third-person  singular  NP. 

In  translating  a  PATR  lexical  entry  into  a  DCG  rule,  the  category  of  the 
word  becomes  the  functor  for  the  left-hand  side  (LHS)  of  the  rule;  its 
argument  list  is  derived  from  the  list  of  unifications.  The  right-hand  side 
(RHS)  of  the  rule  consists  of  the  word  itself.  For  example,  the  above 
lexical  entry  is  equivalent  to  the  DCG  rule 


np( [head:  [agreement ; 

[uther] . 


[person : 
number : 


third, 

singular]]])  — > 


The  example  just  presented  shows  a  very  simple  correspondence  between 
the  PATR  and  the  DCG  formalisms.  For  reasons  explained  in  the  next  sections, 
P-PATR  actually  uses  a  more  complex  compilation  technique. 

^Reentrancy  is  represented  by  sharing  variables. 
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2.3  Left-Corner  Parsing 


The  default  parsing  algorithm  for  DCGs  supplied  by  Prolog  is  a  top-down,  left- 
to-right,  backtracking  algorithm.  A  well-known  problem  with  top-down  parsers 
is  that  left-recursive  grammars  can  cause  them  to  go  into  an  infinite  loop  [1]. 
Because  PATR  rules  are  allowed  to  be  left  recursive,  a  compilation  technique 
must  be  applied  that  enables  the  Prolog  DCG  to  handle  such  rules. 

P-PATR  compiles  a  PATR  grammar  into  a  DCG  that  uses  a  bottom-up 
parsing  algorithm.  Bottom-up  parsers  have  no  problem  with  left  recursion  [1]. 
The  particular  parsing  technique  used  is  called  left-corner  parsing  [11]. 

The  left  corner  (LC)  of  a  CFG  rule  is  the  iirst  symbol  of  the  right-hand  side 
of  the  rule.  For  example,  the  LC  of  the  rule 

S  -►  HP  VP 

is  the  nonterminal  NP.  In  LC  parsing,  each  rule  is  identified  through  its  LC. 
The  first  word  in  the  sentence  functions  as  the  initial  LC  key.  The  rules  whose 
LC  match  the  key  are  extracted.  The  next  word  in  the  sentence  becomes  the 
new  LC  key  for  satisfying  the  remainder  of  the  right-hand  side  of  these  rules. 
If  the  right-hand  side  of  the  rule  is  completely  satisfied,  the  left-hand  side  of 
the  rule  is  substituted  for  the  LC  key  and  the  process  is  iterated.  For  example, 
given  the  CFG  rules 

(3)  S  —  HP  VP 

(4)  VP  V 

(5)  HP-*  H 

(6)  V  — ^  sleeps 

(7)  H  —  Bill, 

the  sentence  “Bill  sleeps”  is  parsed  as  follows; 

LC  key  =  ' 'Bill' ’ 
matches  the  LC  of  Rule  7, 

Rule  7  is  satisfied 

LC  key  =  H 

matches  the  LC  of  Rule  5, 

Rule  5  is  satisfied 

LC  key  =  NP 

matches  the  LC  of  Rule  3, 

leaving  the  VP  of  Rule  3  to  be  satisfied 
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LC  key  =  "sleeps’’ 
matches  the  LC  of  Rule  6, 

Rule  6  is  satisfied 

LC  key  =  V 

matches  the  LC  of  Rule  4, 

Rule  4  is  satisfied 

Rule  3  is  satisfied, 
no  more  input , 
parse  successful 

This  parsing  algorithm  avoids  the  problem  of  left-recursive  rules.® 

The  DCG  produced  by  P-PATR  is  based  on  the  implementation  of  the  LC 
algorithm  in  Matsumoto  et  al.  [6].  Each  PATR  grammar  rule  of  the  type 

RSSi  ...  RSSn 

is  converted  into  a  DCG  rule  of  the  form 

IcCrBSI,  Root)  — > 

doun(RHS2) ,  . . .  ,  down(RHSN) , 

lc(LHS,  Root), 

where  LHS  and  RHSl  through  RHSK  constitute  the  feature  structure  information 
&om  the  unification  list  of  the  rule  and  Root  is  the  feature  structure  of  the 
constitueut  currently  being  parsed.  In  the  limit  case,  Rooi  and  LSS  are  the 
same:  everything  is  its  own  LC. 

IcfRoot,  Root)  — >  □. 

For  example,  consider  a  CFG  for  noun  phrases  consisting  of  a  rule 
BP  — ♦  Oet  i 

and  two  lexical  items:  the:Det  and  girl:ff.  The  corresponding  DCG  rule  pro¬ 
duced  by  P-PATR  is 

lc(det.  Root)  — > 
doyn(n) , 
lc(np.  Root). 

*Epailon  rules  still  poM  a  problem,  but  they  are  taken  care  of  separately  (Section  2.-4), 
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To  understand  how  this  rule  is  used  by  the  Prolog  parser,  we  first  need  to  define 
the  predicates  down  and  leaf: 

down (Cat)  — > 
leaf (Child) , 
lc(Child,  Cat). 

leaf (Child)  — > 

[Word] , 

{lex(Word,  Child)}. 

The  two  words  in  the  grammar  are  defined  by  the  following  Prolog  clauses 

lex(the,  det) 
lex(girl,  n) 

Let  us  now  see  how  the  string  “the  girl”  is  parsed  as  an  NP  by  using  this 
DCG  version  of  the  original  CFG.  The  parse  is  initiated  with  the  call 

down(np) . 

This  results  in  the  call 
leaf (Child), 

which  consumes  the  word  “the”  and  binds  the  variable  Child  to  the  word’s 
category  dot.  The  next  step  is  to  evaluate  the  call 

lc(dat,  np) 

by  finding  a  match  for  this  clause  among  the  LC  rules  and  satisfying  the  right- 
hand  side  of  the  LC  rule.  In  this  case,  we  need  to  satisfy  the  calls 

down(n) 
lc(np,  np) 

The  first  clause  triggers  another  call  to 
leaf (Child), 

which  now  consumes  the  word  “girl”  and  binds  Child  to  n  and  the  call 
lc(n.  n), 
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which  is  immediately  satisfied  because  it  is  an  instance  of  the  rule 
lc(Root,  Root)  — >  □, 
leaving  the  call 

lc(np,  np) 

to  be  satisfied  in  the  same  way. 

The  flow  of  the  computation  can  be  pictured  as  the  tree 


dovn(np) 


leaf (det) 


Icfdet.np) 


the 


downfa.n) 


lc(np,np) 


leaf (n) 


lc(n,ii) 


n 


girl 


[] 


This  obviously  differs  from  the  usual  parse  tree, 
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Det 


N 


the 


girl 


because  of  the  way  the  LC  algorithm  uses  the  rules.  The  standard  phrase- 
structure  tree  can  easily  be  produced  as  a  side  effect  of  the  parse,  if  desired. 

The  above  discussion  is  an  oversimplification.  In  actuality,  the  values  of 
the  V2u:iables  Root,  Cat  and  Child  are  feature  structures  rather  than  atomic 
category  symbols.  For  example,  the  grammar  rule  presented  above  becomes  the 
new  DCG  rule^ 

lc([cat:  np,  head:  [agreement:  Y]] ,  Root)  — > 
doHii([cat:  vp,  head:  [agreement:  Y]]), 
lc([cat:  s,  head:  [agreement:  Y]]),  Root), 

and  the  lexical  entry  for  “Uther”  becomes  the  Prolog  clause 

lex(utber,  [cat:  np, 

head:  [agreement;  [person:  third, 

number :  s ingular] ) ) . 

A  PATR  grammar  is  compiled  into  a  DCG  of  the  form  just  presented.  The 
compilation  technique  is  revised  slightly  in  the  next  section  to  allow  for  the 
epsilon  rules  that  produce  empty  constituents. 


2.4  Epsilon  Rules 
Epsilon  rules  in  a  CFG  are  of  the  form 
A  -+  e 

^Thls  occurs  after  feature  informiition  corresjwndiiig  to  the  categories  of  the  uontemunals 
is  added  to  the  feature  structures  (Section  3.1.2). 
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This  type  of  rule  can  pose  a  problem  in  applying  the  compilation  technique 
described  above.  In  LC  parsing,  a  rule  is  keyed  by  its  left  corner.  If  the  LC  of 
a  rule  can  be  expanded  to  an  empty  string,  the  rule  in  effect  acquires  a  second 
left  corner. 

For  example,  consider  the  rules 

(8)  A  -»  B  A 

(9)  B  e 

Because  B  can  be  expanded  by  rule  9  to  an  empty  string,  rule  8  has  two  left 
corners:  B  and  A.  For  the  compilation  technique  described  above  to  work,  each 
possible  LC  has  to  be  recognized  before  a  rule  is  compiled. 

The  problem  is  solved  in  two  stages.  First,  all  epsilon  rules  are  extracted 
from  the  grammar  and  put  into  a  separate  list.  Then  all  of  the  remaining  rules 
are  examined  one  by  one.  If  the  LC  of  a  rule 

LHS RESi  ...  RHS„ 

can  be  null,  a  new  rule  of  the  form 

LSS  -*  RHS2  ...  RffSn 

is  added  to  the  grammar  and  subjected  to  the  same  test.  For  example,  rule  8 
above  gives  rise  to  the  new  rule 

A  ->  A 

by  virtue  of  the  possible  expansion  of  B  in  rule  8  by  rule  9. 

The  technique  outlined  above  is  easily  extended  to  PATR  grammars.  In  a 
PATR  grammar,  an  epsilon  rule  is  of  the  form 

A  -*  : 

{Definition) . 

In  eliminating  the  epsilon  rules,  the  unification  information  must  be  taken  into 
account.  For  example,  for  the  PATR  grammar  rules 

(10)  A  -*  B  A: 

<A  leaturel>  =  valual 
<B  leature2>  =  <A  leature2> 

(11)  B  : 

<B  ieature2>  =  vaJ.ue2, 
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rule  10  gives  rise  to  the  new  rule 


<A  featurel>  =  valuel 
<A  feature2>  =  value2. 


2.5  Lexical  Organization 

We  now  turn  to  lexical  iemplaies  and  lexical  rules.  Lexical  templates  are  named 
feature  structures  and  lexical  rules  are  named  transformations  on  feature  struc¬ 
tures.  Both  types  of  entries  may  include  references  to  templates  and  rules  in 
their  definition.  Because  templates  and  rules  may  be  referred  to  before  they  are 
defined,  compilation  takes  place  in  two  stages. 

•  Compilation:  First  Stage 

Each  lexical  entry  of  the  PATR  grammar  is  compiled  into  a  temporary 
DCG  rule  of  the  form 

vord(Vord,  FeatureStnicture)  : —  ... 

The  right-hand  side  of  a  temporary  DCG  rule  typically  contains  references 
to  the  lexical  templates  and  lexical'  rules  that  occur  in  the  entry.  These 
references  cannot  be  evaluated,  however,  until  the  first  stage  is  completed. 
The  references  are  of  the  form 

template (Name,  In,  Out) 


or 


lex-rule(Name ,  In,  Out), 

where  In  is  the  input  feature  structure  to  a  rule  or  template,  and  Out  is 
the  output  feature  structure  from  the  rule  or  template. 

For  example,  the  lexical  entry 

Word  Other: 
noun 

is  compiled  into  the  temporary  DCG  rule 

Bord(uther,  FeatureStructure) : — 

ten^il ate (noun.  In,  FeatureStructure), 
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•  Compilation:  Second  Stage 

Once  the  first  stage  has  been  completed,  the  definitions  of  the  lexical  rules 
and  lexical  templates  reside  in  the  Prolog  data  base  (Section  3.2.4).  The 
temporary  rules  produced  in  the  first  stage  of  compilation  could  be  used 
by  the  pau-ser,  but  this  would  be  inefficient  because  the  lexical  templates 
and  rules  would  be  executed  each  time  they  are  referred  to. 

At  this  point,  each  lexical  entry  is  executed  once  by  Prolog,  evaluating  the 
actions  of  the  rules  and  templates,  and  the  new  feature  structure  produced 
is  used  in  converting  the  entry  to  its  final  form. 

For  example,  the  temporary  DCG  rule 

word(boy,  FeatnreStructnxe) : — 

templateCnoim,  In,  FeatuxeStmctnre) 

produces  the  final  DCG  rule 

lex (boy.  [cat:  n])) 

once  it  is  executed. 
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compilation  module 


Clausal  Form 


input  module 


PATR  Grammar 


Figure  1:  Flow  Diagram  of  P-PATR 


3  The  P-PATR  System 


This  section  provides  a  step-by-step  account  of  the  compilation  technique  used 
by  P-PATR.  An  overview  of  the  process  is  given  in  Figure  1.  As  shown  in 
the  diagram,  compilation  is  accomplished  in  two  phases:  grammar  input  and 
grammar  compilation.  The  grammar  input  phase  produces  an  intermediate 
representation  of  the  PATR  grammar  that  is  used  in  the  compilation.  During 
compilation,  information  is  both  written  to  a  file  reserved  for  the  output  DCG 
and  asserted  into  the  Prolog  data  base.  The  information  in  the  data  base  is 
accessed  as  the  compilation  proceeds. 

3.1  Grammar  Input 

This  phase  takes  a  set  of  text  files  containing  a  PATR  grammar  and  converts  it 
to  a  Prolog  clausal  form  used  by  later  phases.  The  grammar  is  entered  in  two 
distinct  steps:  tokenization  and  translation. 
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3.1.1  Tokenization 


Each  entry  in  the  PATR  grammar  is  first  tokenized  and  then  translated  into 
clausal  form.  There  are  six  classes  of  tokens  recognized  by  the  P-PATR  tok- 
enizer:  identifiers,  special  characters,  terminators,  white-space  characters,  com¬ 
ments  and  strings.  Each  token  type  is  briefly  described  below. 

•  Identifiers 

Identifiers  are  tokens  that  consist  of  any  alphanumeric  characters:  a-z, 
A-Z,  and  0-9;  and  any  special  intraword  characters:  underbar  (.),  asterisk 
(*),  apostrophe  (’),  questionmark  (?),  and  backquote  (‘). 

•  Special  Characters 

Special  chauacters  are  tokens  consisting  of  a  single  character:  colon  (:), 
number  sign  (#),  slash  (/),  arrow  (— »),  square  brackets  ([,]),  angle 
brackets  (<,  >),  braces  ({,  }),  parentheses  ((,  )  ),  comma  (,),  equal  sign 
(=),  or  dash(-).  A  sequence  of  tokens  consisting  of  a  dash  (-)  and  a  right 
angle  bracket  (>)  is  treated  as  the  single  token;  arrow  (— ►). 

•  Terminators 

Terminators;  period  (.)  and  endjofJile,  signal  the  end  of  a  token  stream. 
Terminators  are  considered  a  special  case  of  special  characters  and  are 
treated  as  the  single  tokens;  period  (.)  and  end-of_file. 

•  White-space  Characters 

White-space  characters:  space,  newline,  tab  and  formfeed  are  ignored. 

•  Comments 

Comments,  which  begin  when  the  single-token  semicolon  (;)  is  encountered 
and  continue  to  the  end  of  the  line,  are  ignored. 

•  Strings 

Strings  are  any  list  of  characters  enclosed  in  double  quotes  ('*).  Embedding 
of  double  quotes  inside  a  string  is  done  by  using  a  sequence  of  two  double 
quotes  (""). 

In  all  tokens,  except  for  strings,  no  case  distinction  is  made.  All  characters 
are  converted  to  lowercase.  Any  characters  that  are  not  legal  in  a  P-PATR 
token  are  ignored  and  a  warning  is  issued. 
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3.1.2  Translation 


The  stream  of  tokens  produced  by  the  tokenization  process  is  now  translated 
into  clausal  form.  Each  type  of  entry  in  the  PATR  grammar  is  translated  into 
a  form  that  will  be  most  appropriate  in  subsequent  compilation  (Section  3.2), 
as  follows: 


Control  Siaiemenis 

The  only  type  of  control  statement  is  the  input  statement.  Input  statements 
are  of  the  form 

Input  {InpuiFile). 

When  an  input  statement  is  encountered  during  translation,  the  current  input 
file  is  temporarily  replaced  by  the  file  specified  in  the  statement.  Once  this  new 
file  is  completely  read  in,  the  old  input  file  is  restored. 

For  example,  the  input 
Input  'testgram*. 

causes  the  current  input  stream  to  become  the  file  TESTGRAM. 

Parameters 

P-PATR  recognizes  two  grammar-dependent  parameters;  start  symbol  and  af- 
trihuit  order.  These  parameters  are  set  by  statements  that  must  appear  in  the 
grammar  before  any  rules  or  lexical  items  are  encountered.  Other  parameters® 
are  ignored. 

The  parameter  statements  are  processed  as  follows: 

•  Start  Symbol 

The  start  symbol  is  defined  by  a  statement  of  the  form 

Parameter:  Stzirt  Symbol  is  {Symbol}. 

The  start  symbol  for  the  grammar  is  recorded  for  use  in  further  compila¬ 
tion  as  a  clause  of  the  form 

parameter (start (Symbol)) . 

^There  are  several  other  parameters  that  can  be  specified  In  a  PATR  grammar,  but  their 
information  is  not  utilized  by  this  implementation. 
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•  Aiiribuie  Order 

Attribute  order  is  specified  as  follows 

Parameter:  attribute  order  is  {AUribuies}. 

This  is  converted  to  the  Prolog  clause 

parameter  Cattributes (List) ) . 

where  List  corresponds  to  a  list  of  all  attributes  in  the  order  specified. 
For  example,  the  input 

Parameter:  attribute  order  is  cat  head, 
produces  the  clause 

parameter (attributes ( [cat ,  head] ) ) . 


Grammar  Rules 

The  format  for  PATR  grammar  rules  is 
Rule  {  {Description)  } 

(LES)  —  {RES}: 

{Definition) . 

In  translating  the  rule  into  clausal  form,  all  nonterminals  are  replaced  by  vari¬ 
ables,  which  are  used  during  compilation.  Grammar  rules  are  translated  into  a 
clause  of  the  form 

rule(LHS.  RHS,  Dei) 

where  LBS  is  a  variable  associated  with  the  left-hand  side  of  a  rule,  RHS  is  a  list 
of  variables  associated  with  the  right-hand  side  of  the  rule,  and  Del  is  a  list  of 
specifications  defining  the  rule. 

In  the  original  PATR  grammar,  the  category  information  of  a  nonterminal 
can  be  omitted  from  the  list  of  unifications  because  it  is  added  automatically 
during  grammar  translation.  For  example,  the  grammar  rule 

Rule  {  sentence  lormation  } 

S  —  HP  VP: 

<S  head>  =  <VP  head> 

<S  head  lorm>  =  finite 
<VP  subcat  lixst>  =  <HP> 

<VP  BUbcat  rest>  =  end 
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produces  the  clause 

ruleCS.  [NP,  VP],  [[S,  cat]  =  s, 

[KP,  cat]  =  np, 

[VP,  cat]  =  vp, 

[S,  head]  =  [VP,  head], 

[S,  head,  form]  =  finite, 

[VP,  subcat,  first]  =  [NP] , 

[VP ,  subcat ,  rest]  =  end] ) , 

where  the  unification  information 

[S,  cat]  =  s 
[NP,  cat]  =  np 
[VP,  cat]  =  vp 

is  added  to  the  list  of  unifications.  The  only  exception  is  the  nonterminal  X 
(with  or  without  a  subscript).  If  this  appears  in  a  grammar  rule,  no  category 
information  is  added,  thus  allowing  expressions  of  any  category  to  appear  in 
this  position. 

P-PATR  follows  the  Z-PATR  [18]  convention  for  distinguishing  among  con¬ 
stituents  that  have  the  same  category.  This  is  accomplished  by  means  of  numeric 
tags.  For  example,  if  two  constituents  in  the  same  rule  are  referred  to  as  VP_1 
and  VP_2,  they  are  both  of  category  VP. 


Lexical  Items 

Each  type  of  lexical  item  in  a  PATR  grammar  is  translated  accordingly: 

•  Lexical  Entries 

The  format  for  lexical  entries  is 

Vord  { Word) : 

{Dejinitior^ . 

In  translating  a  lexical  entry  into  claused  form,  the  information  from  the 
original  PATR  entry  is  left  unchanged.  Thus,  lexical  entries  are  translated 
into  clauses  of  the  form 

lex (Word,  Def ) , 
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where  Word  is  a  word  being  defined,  and  Dei  a  list  of  specifications  defining 
the  word. 

The  system  augments  each  lexical  entry  with  two  new  features;  lex  and 
sense.  It  is  assumed  that  the  lexical  entry  does  not  already  contain  this 
information;  otherwise  it  will  be  duplicated.  The  lex  value  for  a  lexical 
entry  is  the  word  itself.  The  sense  value  is  the  word  concatenated  with 
a  number  that  specifies  how  many  previous  definitions  of  this  word  have 
occurred  in  this  grairunar.  For  example,  given  the  entry 

Word  Uther; 

<cat>  =  HP 

<head  sigreement  gender>  =  masculine 

<head  cigreement  person>  =  third 

<head  agreement  number>  =  singular 

<head  trans>  =  Uther, 

P-PATR  produces  the  clause 

lex (uther,  [[lex]  =  uther, 

[sense]  =  uther, 

[cat]  =  np, 

[head,  agreement,  gender]  =  masculine, 

[head,  agreement,  person]  =  third, 

[head,  agreement,  number]  =  singular, 

[head,  trans]  =  uther]). 

If  there  already  exists  one  previous  definition  for  the  word  “Uther”,  the 
value  for  the  sense  feature  in  the  second  definition  would  be  uther2. 

•  Lexical  Templates 
Lexical  templates  are  of  the  form 

Let  {Template)  be 
{Definition) . 

In  translating  a  lexical  template  into  clausal  form,  the  information  &om 
the  original  PATR  lexical  template  is  left  unchanged.  Thus,  lexical  tem¬ 
plates  are  translated  into  clauses  of  the  form 

template (Name,  Del), 

where  Same  is  the  name  of  a  lexical  template  being  defined,  and  Del  a  list 
of  specifications  defining  the  template. 

For  example,  the  template 
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Let  verb  be 
<cat>  =  V. 

produces  the  clause 

template (verb,  [[cat]  =  v]). 

■  Lexical  Rules 
Lexical  rules  have  the  form 

Define  {Rule)  as 

{Definition) . 

In  the  clausal-form  encoding  of  the  lexical  rule,  the  in  and  out  attributes 
are  replaced  by  variables,  which  are  used  during  compilation.  Thus,  lexical 
rules  are  translated  into  clauses  of  the  form 

lex_rule{Kame,  In,  Out,  Def) 

where  Hame  is  the  name  of  a  lexical  rule  being  dehned,  In  is  a  variable 
associated  the  with  the  input  to  the  rule,  Out  is  a  variable  associated  with 
the  output  of  the  rule,  and  Def  is  a  list  of  specifications  defining  the  rule. 

For  example,  the  rule 

Define  agentlesspassive  as: 

<out  cat>  =  <in  cat> 

<out  subcat>  =  <in  subcat  rest> 

<out  head  agreement>  =  <ia  head  agreemeiit> 

<out  head  aux>  =  <in  head  aux> 

<out  head  tran.s>  =  <in  he2ul  tranB> 

<out  head  form>  =  passiveparticiple . 

produces  the  clause 

lez-rule(agentlesspassive.  In,  Out, 

[ [Out ,  cat]  =  [In ,  cat] , 

[Out,  subcat]  =  [la,  subcat,  rest], 

[Out,  head,  agreement]  =  [In,  head,  agreement], 
[Out ,  head ,  aur]  =  [In ,  head ,  aur] , 

[Out,  head,  trans]  =  [In,  head,  trans] , 

[Out,  head,  form]  =  pzmsiveparticiple]) . 
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Grammar  Compilation 


3. 


This  phase  tcikes  a  text  file  containing  a  PATR  grammar  in  clausal  form  and 
compiles  it  into  a  Prolog  DCG.  Grammar  compilation  is  accomplished  in  five 
distinct  phases;  parameter  processing,  attribute  position  generation,  epsHon  pre~ 
compilation,  compilation,  and  lexical  compilation. 

3.2.1  Parameter  Processing 

This  phase  processes  the  parameter  statements  specified  in  the  PATR  grammar. 
Parameter  statements  must  occur  first  in  the  graiiunar  to  ensure  thei<-  uss  in 
the  entire  compilation. 

The  two  types  of  parameter  statements  are  treated  as  follows: 

•  Start  Symbol 

A  statement  of  the  form 

parameter (start (Symbol) ) 

is  asserted  into  the  Prolog  data  base  and  written  to  the  DCG  file  as 
start (Symbol) . 

•  Attribute  Order 

The  attribute  order  is  initially  represented  in  clausal  form  as 
parameter(attributes(List)) , 

where  List  is  a  list  of  attributes  with  a  specified  order. 

For  e^lch  attribute  in  the  list,  a  clause  is  asserted  into  the  Prolog  data 
base  specifying  the  order  of  that  attribute.  This  information  is  used  in 
maintaining  the  specified  order  during  output  of  the  feature  structures. 

This  information  is  asserted  into  the  Prolog  data  base  as 

print_order (Attribute ,  Position) , 

where  Attribute  is  an  attribute  from  the  fist  of  attributes,  and  Position 
is  the  position  of  that  attribute  in  the  list  of  attributes. 

For  example,  given  the  parameter  statement 

parameter(attributes ( [cat ,  head] ) , 
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the  clauses 


print-order  (cat,  1) 
print-order  (head,  2) 

are  asserted  into  the  Prolog  data  base. 


3.2.2  Attribute  Position  Generation 

In  PATR,  feature  are  pairs  of  attributes  and  values.  The  value  of  an  attribute 
can  be  one  of  three  types:  indeterminate,  atomic,  and  complex.  A  complex  value 
is  a  set  of  attribute-value  pairs.  In  the  following  discussion  only  the  complex 
values  contribute  information  about  the  attributes;  therefore,  the  other  types 
of  values  are  not  discussed. 

This  phase  computes  the  arity  of  each  complex  attribute  value  aind  places 
the  features  in  a  fixed  order.  The  information  is  used  in  the  conversion  of  PATR 
feature  structures  to  Prolog  terms  (Section  2.1). 

For  each  attribute  in  a  PATR  grammar,  a  list  is  compiled  that  consists  of 
all  the  attributes  that  can  follow  that  attribute  in  a  path  specification.  For 
example,  given  the  lexical  template 

teinplate(singular,  [[head,  agreement,  number]  =  singular]), 

the  information  recorded  for  the  attribute  head  is  that  it  can  be  followed 
by  agreement  in  a  path  specification.  The  information  that  the  attribute 
agreement  can  be  followed  by  number  is  also  recorded. 

Once  all  information  on  the  attributes  has  been  compiled,  this  information 
is  translated  into  clausal  form  and  is  asserted  into  the  Prolog  data  base  and 
written  to  the  DCG  file  as 

feature-order (Attribute,  Features,  Variables) 

where  Attribute  is  the  attribute  currently  being  described.  Features  is  a  list 
of  pairs  consisting  of  an  attribute  and  a  unique  variable  representing  the  value 
of  that  attribute,  and  Variables  is  a  list  of  the  variables  in  Features. 

For  example,  from  the  above  template  the  following  clauses  are  generated 
and  asserted  into  the  Prolog  data  base: 

feature-orderfmain,  [head:l] ,  [1]) 
feature-order  (head,  [agreement :  Y]  ,  [Y]) 
f eature-order(agreement ,  [number  :Z],  [2]). 
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A  dummy  attribute  main  is  created  to  notate  those  features  that  can  occur  as 
the  first  feature  in  a  path  specification. 

Since  the  list  Features  is  used  during  the  output  of  the  feature  structures, 
the  order  of  the  attributes  must  reflect  the  order  specified  in  the  parsuneter 
statement.  Thus,  the  list  is  reordered,  to  reflect  the  specified  order.  Any  at¬ 
tributes  whose  order  is  not  determined  are  just  added  to  the  end  of  the  list  of 
features. 


3.2.3  Epsilon  Precompilation 

This  pass  through  the  PATR  grammar  precompiles  epsUon  rules. 

Epsilon  rules  are  represented  in  clausal  form  as 

ruleCLHS,  □,  Def), 

where  the  grammar  rule  has  no  right-hand  side.  All  other  grammar  entries  are 
ignored  during  this  pass. 

An  epsilon  rule  is  compiled  into  a  DCG  rule  by  applying  the  unification 
equations  attached  to  the  rule,  thereby  producing  a  feature  structure  associated 
with  the  rule  (Section  2,1).  The  compiled  epsilon  rule  is  then  asserted  into  the 
Prolog  data  base  and  written  to  the  DCG  file  as 

nulKLHS) 

where  LHS  is  the  feature  structure  associated  with  the  rule. 

For  example,  the  epsilon  rule 

rule(Det,  □,  [[Det,  head,  agreement,  number]  =  plural]) 
is  outputted  as 

null {[cat:  det,  head:  [agreement:  [number:  plural]]]). 


3.2.4  Compilation 

This  pass  through  the  PATR  grammar  uses  the  information  produced  in  the 
previous  phases  to  generate  a  DCG  rule  for  each  grammar  entry.  These  DCG 
rules  are  written  to  the  DCG  file  (grammar  rules)  or  recorded  in  the  data  base 
to  be  further  processed  during  the  second  compilation  stage  (lexical  items). 

Each  type  of  grammar  entry  is  compiled  into  a  DCG  rule  as  follows: 
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Grcunmar  Rules 


All  of  the  unification  equations  in  the  grammar  rule  are  applied  (Section  2.1), 
producing  the  feature  structures  associated  with  the  rule.  For  example,  the  LHS 
and  RHS  variables  of  the  rule 

rulefVP,  [V],[[VP,  cat]  =  vp, 

CV,  cat]  =  V, 

[VP,  head]  =  [V,  head], 

[VP,  subcat]  =  [V,  subcat]]) 

become 

VP  becomes  [cat:  vp 
head :  X 
subcat :  Y] 

V  becomes  [cat:  v 
head :  X 
subcat :  Yj . 

These  feature  structures,  together  with  the  rule  itself,  are  now  compiled  into 
a  DCG  rule  in  left-corner  format  (Section  2.3). 

At  this  pomt,  the  solution  to  the  problem  caused  by  epsilon  rules  is  applied 
(Section  2,4).  As  a  result,  one  rule  may  expand  to  a  set  of  rules.  These  rules 
Eire  written  to  the  DCG  file  in  a  form  that  is  slightly  more  complex  than  that 
presented  in  Section  2.3 

IcfRHSl,  Parent,  Branchl,  Tree)  — > 

do¥ii(RHS2,  Branch2),  ...  ,  down(RHSH,  BranchK) , 

IcCLHS,  Parent,  HeuTree,  Tree) 

where  RBSl  through  RHSK  are  the  feature  structures  associated  with  the 
right-hand  side  of  the  rule.  Parent  is  the  feature  structure  associated  with 
the  left-hand  side  of  the  rule,  Branchl  through  BranchN  £«■€  the  parse  trees 
associated  with  the  right-hand  side  of  the  rule,  Tree  is  the  parse  tree  associated 
with  the  left-hand  side  of  the  rule,  and  KewTree  is  the  peirse  tree  associated  with 
the  entire  rule. 

For  example,  the  rule  presented  above  becomes  the  DCG  rule 
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lc(Ccat:  V, 
head :  X , 
subcat :  Y]  , 

Parent,  Branchl,  Tree)  — > 
IcCCcat:  vp, 
head :  X , 
subcat :  Y]  , 

Parent,  vpCBrauchl) ,  Tree). 


Lexical  Items 

Each  lexical  item  in  the  grammar  is  compiled  into  a  DCG  rule.  These  rules, 
unlike  grammar  rules,  are  not  written  directly  to  the  DCG  file.  They  are  asserted 
into  the  Prolog  data  base  to  be  compiled  and  written  to  the  DCG  file  in  a  later 
stage. 

Each  type  of  lexical  item  is  asserted  into  the  Prolog  data  base  with  a  different 
functor  but  they  are  processed  in  the  same  way.  First,  all  of  the  specifications 
in  the  definition  are  processed.  If  a  specification  is  a  unification,  it  is  applied 
(Section  2.1);  if  it  is  a  reference  to  a  lexical  rule  or  lexical  template,  the  reference 
is  put  into  the  form 

template (Name,  In,  Out) 


or 


lex.rule(Name,  In,  Out), 

where  In  is  the  input  feature  structure  to  a  rule  or  template,  and  Out  is  the  out¬ 
put  feature  structure  from  the  rule  or  template.  These  references  are  expanded 
in  the  second  compilation  phase. 

•  Lexical  Entries 

Lexical  entries  are  asserted  into  the  Prolog  data  base  in  the  form 

word(Word ,  FeatureStructure) : — 

Del. 

where  Word  is  the  name  of  a  lexical  entry,  FeatureStructure  is  the  feature 
structure  associated  with  the  lexical  entry,  and  Del  includes  references  to 
rules  and  templates  producing  FeatureStructure. 

For  example,  the  lexical  entry 

lexfutber,  [[lex  =  uther] ,  [sense  =  utherl] ,  noun]) 
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is  compiled  into 


BordCuther,  FeatureStmctuxo) :  — 

template (noun,  [lei:  uther,  sense:  utherl] , 
FeatureStnicture) . 


•  Lexical  Templaies 

Lexical  templates  are  asserted  into  the  Prolog  data  base  in  the  form 

templateCName,  FeatureStnicture): — 

Def , 

where  Name  is  the  name  of  a  lexical  template,  FeatureStnicture  is  the 
feature  structure  associated  with  the  template,  and  Def  includes  references 
to  rules  and  templates  producing  FeatureStnicture. 

For  example,  the  lexical  template 

template (mainverb,  [[head,  aui  =  false],  verb]) 
is  compiled  into 

template(mainverb,  FeatureStnicture) : — 

template (verb,  [head:  [aui:  false]] , 
FeatureStnicture) . 


•  Lexical  Rules 

Unlike  lexical  entries  and  lexical  templates,  lexical  rules  are  not  allowed  to 
contain  references  to  rules  or  templates  in  their  dehnition.  Thus,  lexical 
rules  are  asserted  into  the  Prolog  data  base  in  the  form 

lex.rule(Name ,  In,  Out). 

where  Name  is  the  name  of  a  lexical  rule,  In  is  the  feature  structure  associ¬ 
ated  with  the  input  to  the  rule,  and  Out  is  the  feature  structure  associated 
with  the  output  from  the  rule. 

For  example,  the  lexical  rule 

lexjrule(nom,  [[Out,  head]  =  [In,  head],  [Out,  cat]  =  n]) 
is  compiled  into 

leUTile(nom,  [cat:  v,  head:  X],  [cat:  n,  head:  X]). 
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3,2.5  Lexical  Compilation 

Lexical  entries  are  initially  compiled  into  DCG  rules  with  explicit  calls  to  the 
templates  and  lexical  rules  they  utilize.  Because  these  calls  are  re-executed 
each  time  they  are  encountered,  the  system  would  be  inefficient  to  use.  At 
the  second  stage  of  compilation,  these  references  are  eliminated  by  merging  the 
corresponding  feature  structures  with  the  rest  of  the  definition. 

Once  this  process  is  completed,  the  DCG  rules  for  the  lexical  entries  no 
longer  contain  any  references  to  lexical  templates  or  rules;  therefore,  the  rules 
and  templates  need  not  be  recorded  in  the  DCG  file. 

The  new  lexical  entries  are  written  to  the  DCG  file  as 

lexfWord,  FeatureStructure) . 

For  example,  the  initial  DCG  rules 

a ord ( boy ,  Y) : — 

template (noun,  X,  Y) . 
template (noun,  X,  Y) : — 

Y  =  [cat :  nj  . 

produce  the  new  DCG  rule 

lexfboy ,  [cat :  n] ) . 
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Sentence 

Parse  time  {in  seconds) 

Uther  sleeps 

Uther  storms  Cornwall 

Knights  sleep 

0.084 

Cornwall  is  stormed 

0.1 

A  knight  storms  Cornwall 

0.1 

Table  1;  Execution  Statistics 


4  Conclusions 

To  test  whether  the  P-PATR  system  lives  up  to  the  expectations  that  motivated 
its  development,  it  will  be  necessary  to  compare  it  with  the  two  other  currently 
running  PATR  systems:  D-PATR  [5]  and  Z-PATR  [18].  Because  of  disparities  in 
the  versions  of  the  PATR  formalism  assumed  by  each  system,  accurate  statistics 
are  not  presently  available,  but  the  preliminciry  results  seem  promising. 

Sample  execution  statistics  can  be  seen  in  Table  1.  These  are  the  execution 
results  Rom  the  DCG  produced  by  P-PATR,  using  as  input  the  grammar  in 
Section  B.  It  is  easy  to  see  from  these  statistics  that  a  DCG  produced  by 
P-PATR  is  a  speedy  parsing  tool. 

4.1  Further  Work 

P-PATR  is  far  from  complete.  Changes  are  being  made  to  improve  the  sys¬ 
tem’s  performance  and  expand  its  capabilities.  These  enhancements  include 
the  following; 

•  Improved  Parser  Performance 

Because  Prolog  uses  a  depth-first  control  strategy,  a  DCG  generates  the 
first  parse  for  a  sentence  quickly,  but  when  all  parses  must  be  produced,  the 
necessary  backtracking  slows  the  parse  down  significantly.  To  solve  this 
problem,  predictive  [9]  capabilities  will  be  added  to  P-PATR  to  eliminate 
some  of  the  superfluous  backtracking  so  that  all  parses  can  be  found  faster. 

•  CompaiibilUy  with  the  Other  PATR  Systems 

To  allow  better  comparisons  of  performance,  it  would  be  desirable  to  be 
able  to  run  the  same  grammar  on  P-PATR  as  on  the  other  two  systems 
discussed  above.  Some  work  is  currently  being  done  [16]  on  developing  a 
standard  specifying  a  single  version  of  the  PATR  formalism  to  which  all 
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PATR  systems  would  conform.  Once  this  is  done,  the  same  grammar  can 
be  used  with  equal  ease  on  all  PATR  systems. 

•  Morpfiological  Analysis 

P-PATR  does  not  currently  perform  morphological  analysis.  For  each  form 
of  a  lexical  entry  in  a  PATR  grammar,  a  separate  entry  in  the  grammar 
must  be  present.  By  encorporating  the  work  being  done  on  morphological 
analysis  in  the  PATR  frzimework  [2]  into  P-PATR,  only  the  stem  forms  of 
the  lexical  entries  need  be  entered  into  the  lexicon. 


32 


A  User’s  Manual  for  the  P-PATR  System 
A.l  Starting  Up  the  System 

To  start  P-PATR,  load  the  file  LOADPATR.PL  into  the  Prolog  data  base.®  This 
file  loads  the  rest  of  the  system  and  initializes  all  execution  flags. 


A.I.l  Loading  Necessary  Files 

The  P-PATR  system  consists  of  three  basic  modules:  READPATR.PL,  COM- 
PILEPATR.pl  and  PATRLIBRARY.PL.  Each  of  these  modules  is  in  turn  di¬ 
vided  further  into  submodules,  which  are  loaded  by  their  parent  module.  A 
complete  list  of  all  files  that  must  reside  in  the  Prolog  data  base  for  compilation 
to  proceed  is  given  below. 


READPATR.PL 

This  module  includes  all  files  necessary  for  translating  a  PATR  grammar  into 
clausal  form.  The  files  are: 

•  READTOKENS.pl :  Reads  in  a  PATR  rule  and  returns  it  as  a  list  of 
tokens. 

•  READPATR.PL;  Takes  a  list  of  tokens  and  translates  it  into  clausal  form. 

COMPILEPATR.PL 

This  module  includes  all  the  files  that  are  necessary  in  converting  a  clausal 
representation  of  a  PATR  grammar  to  a  Prolog  DCG.  The  files  are 

•  COMPILEPATR.PL:  Compiles  a  clausal  form  into  a  DCG. 

•  READRULES.PL;  Reads  in  a  list  of  PATR  rules. 

•  PARAMETERS. PL:  Records  the  information  contained  in  the  parameter 
statements. 

•  PATHS.PL:  Compiles  all  information  on  the  position  and  order  of  the 
features. 

^Loading  a  file  into  Prolog  involves  either  compiling  or  inteipr^thig  that  file.  The  current 
implementation  compiles  these  files,  but  the  system  could  easily  be  modified  to  inteipret  them, 
if  desired.  The  difference  Js  that  it  takes  longer  to  compile  than  to  interpret  a  Prolog  file,  but 
a  compiled  file  executes  much  faster. 
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•  EPSILONS.PL;  Preprocesses  al!  epsilon  rules. 

•  GOMPILEGRAMMAR.PL:  Performs  the  actual  compilation  of  the  gram¬ 
mar  entries. 

•  UNIFY.PL:  Applies  the  unification  equations  constraining  a  rule. 

•  COMPILELEX.PL:  Compiles  ail  lexical  entries. 

patrlibrary.pl 

This  module  consists  of  a  single  file  that  contains  predicates  common  to  all  of 
the  modules.  The  predicates  included  perform  basic  operations  needed  by  the 
entire  system. 


A. 1.2  Trace  Flags 

In  LOADPATR.pl,  there  Eire  four  execution  flags  that  can  be  toggled  by  the 
user; 


•  traceAnput  (default  no):  Yes  prints  out  the  clausal  representation  of 
•  each  PATR  rule  as  it  is  processed  in  the  grammar  input  module. 

•  trace.paths  (default  no):  Yes  prints  the  feature  information  compiled 
during  execution  of  the  attribute  position  generation  module. 

•  trace_raZes  (default  no):  Yes  prints  out  each  DCG  rule  as  it  is  processed 
in  the  compilation  module. 

•  load.paxser  (default  yes):  Ho  suppresses  the  loading  of  the  compiled 
DCG  after  compilation. 

lb  change  the  values  of  any  of  the  execution  flags,  the  user  must  modify  the 
values  in  LOADPATRPL.i° 


A. 2  Compiling  a  PATR  Grammar 

Once  all  of  the  necessary  files  reside  in  the  Prolog  data  base,  the  system  is  ready 
for  use. 

^’’The  values  can  also  be  changed  later  by  means  of  the  Prolog  predicates  abolish  and 
assert  [3]. 
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A.2.1  Grammar  Input 


The  file  to  be  compiled  must  first  be  translated  into  clausal  form  by  a  call  to 
the  grammar  input  module.  The  calling  sequence  is 

grammar (File) , 

where  the  name  of  the  file  to  be  compiled  can  be  any  Prolog  atom  or  string  [3]. 

The  grammar  input  module  then  translates  the  file  into  clausal  form  and 
puts  the  output  into  a  new  file  whose  name  is  that  of  the  initial  file  with  the 
new  file  type  extension  PTRP.  When  the  input  module  is  invoked,  it  displays 
the  message 

‘  'Reading  ..." 

and,  once  input  is  completed,  the  execution  time  (in  seconds)  of  the  input 
module  is  printed. 

Bor  example,  the  file  DEMOGRAM.PATR  is  translated  into  clausal  form 
through  the  call 

grammar ( 'demogram.patr' ) , 

producing  the  new  file  DEMOGRAM.PTRP. 


A.2.2  Grammar  Compilation 

Once  the  PATR  grammar  is  in  clausal  form,  it  is  compiled  into  a  Prolog  DCG 
by  a  call  to  the  grammar  compilation  module.  The  calling  sequence  is 

con5)ilepatr(File)  , 

where  the  file-type  extension  of  the  file  name  may  be  omitted,  as  it  is  assumed 
to  have  the  extension  PTRP. 

The  grammar  compilation  module  then  compiles  that  file  into  a  DCG  and 
puts  the  output  into  a  new  file  whose  name  is  that  of  the  initial  file  with  the  new 
file-type  extension  DCG.  When  the  compilation  module  is  invoked  it  displays 
the  following 

"Compiling  ..." 
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and,  once  compilation  is  completed,  the  execution  time  (in  seconds)  of  the  com¬ 
pilation  module^^  is  displayed. 

For  example,  the  file  DEMOGRAM.PTRP  is  compiled  through  the  call 
compilepatrCdesiogran) , 
producing  the  new  file  DEMOGRAM.DCG. 

A. 3  Parsing  a  Sentence 

A.3.1  Loading  the  DCG 

Once  the  PATR  grammar  is  compiled,  the  DCG  file  is  loaded  into  the  Pro¬ 
log  data  base.^^  When  loaded,  the  DCG  file  itself  loads  a  support  module 
PATRSUPPOKT.PL  containing  additional  predicates  that  are  needed  in  pars¬ 
ing.  PATRSUPPORT.pl  also  loads  a  submodule  PP.PL  that  contains  a  feature 
structure  pretty  printer,  as  well  as  submodule  READIN.PL  that  includes  a  sen¬ 
tence  reader.  In  all,  the  files  that  must  reside  in  the  Prolog  data  base  before 
parsing  can  proceed  are 

•  File.DCG;  DCG  file  produced  by  compilation  module. 

•  PATRSUPPORT.PL:  Support  module  for  the  parser. 

•  PP.PL;  Feature  structure  pretty  printer. 

•  READIN.PL:  Sentence  reader. 

A.3.2  Sentence  Parsing 

Once  all  necessary  files  are  loaded,  sentences  can  be  parsed  by  entering  the 
statement 

patr. 

The  parser  is  now  ready  for  input. 

*'This  is  not  completely  accurate.  The  execution  time  of  the  compilation  module  is  dis¬ 
played  to  two  steps.  First,  the  execution  time  of  the  compilation  itself  is  displayed  and  if  the 
load_pax8er  execution  flag  has  been  toggled  on,  a  second  execution  time  is  displayed  that 
corresponds  to  the  loading  time. 

^^This  can  be  done  by  toggling  an  execution  flag  or  by  loading  it  manually  into  the  Prolog 
data  base. 
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Sentence  Input 

The  input  environment  consists  of  an  input  loop  for  the  sentences'.  Each  sentence 
entered  at  the  prompt  is  parsed.  End  of  input  is  signaled  by  the  command 
“control-d"  entered  at  the  input  prompt. 


Parser  Output 

Once  a  sentence  is  parsed,  four  pieces  of  information  are  returned  by  the  parser: 

•  Number  of  parses 

The  number  of  parses  for  the  sentence. 

•  Execution  time 

The  time  (in  seconds)  that  it  took  to  parse  the  sentence. 

•  Parse  tree 

A  parse  tree  is  displayed  for  each  of  the  parses  for  the  sentence.  The  parse 
tree  is  represented  as  a  parenthesized  list. 

For  example,  for  the  sentence  “Uther  sleeps”  the  parse  tree  might  be 
s(np(n(uther) ) ,  vp(v(sleeps))) 

•  Feature  structure  corresponding  to  the  sentence 

A  feature  structure  for  each  of  the  parses  for  a  sentence  is  displayed  as  an 
at  tribute- value  matrix. 

For  example,  a  possible  feature  structure  associated  with  the  sentence 
“Uther  sleeps”  is  represented  as 

[c  at :  s 

head:  [form:  finite 

trans:  [pred:  sleep 

argl :  uther] 
aux:  false]] 


37 


A.4  Sample  Session  with  the  P-PATR  System 


The  following  is  a  transcript  of  a  session  with  P-PATR,  using  the  grammar  in 
Section  B. 


Quintus  Prolog  Release  1.6  (Sun) 

Copyright  (C)  1986,  Quintus  Computer  Systems,  Inc. 
All  rights  reserved. 

I  ?-  compile (loadpatr) . 

[pp.pl  compiled  (7.350  sec  1848  bytes)] 

[readin.pl  compiled  (2.450  sec  964  bytes)] 
[patrsupport , pi  compiled  (18.017  sec  5552  bytes)] 
[patrlibrary.pl  compiled  (2.100  sec  728  bytes)] 
[readtokens.pl  compiled  (9.634  sec  2968  bytes)] 
[readpatr.pl  compiled  (28.716  sec  9948  bytes)] 
[readrules.pl  compiled  (1.067  sec  432  bytes)] 
[paths.pl  compiled  (12.717  sec  3700  bytes)] 
[epsilons.pl  compiled  (1.317  sec  620  bytes)] 
[parameters. pi  compiled  (1.850  sec  496  bytes)] 
[compilegrammar.pl  compiled  (5.483  sec  1520  bytes)] 
[compilelex.pl  compiled  (0.634  sec  244  b3rteB)] 
[unify.pl  compiled  (3.950  sec  900  bytes)] 
[compilepatr.pl  compiled  (29.833  sac  9388  bytes)] 
[loadpatr.pl  compiled  (79.850  sec  26588  bytes)] 

yes 

I  ?-  grammar( ’sample. patr’) • 

Reading  ... 

Rxmtime  =  11.899994 
yes 

I  ?-  compilepatr(sample) . 

Compiling  . . . 

Runtime  =  5.633995 
Loading  . . , 

[sample. deg  compiled  (20.633  sec  3728  bytes)] 
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yes 

I  ?-  patr. 

1:  Uther  sleeps. 

Runtime  =  0.066000 

Analysis  #  1: 

Parse  Tree  =  s(np(uther) , vpCvCsleeps)) ) 
[cat:  s 

head:  [form:  finite 

trans:  [pred:  sleep 
argl :  uther] 
aux:  false]] 


Number  of  Parses  =  1 
I  :  Comuall  is  stormed. 

Runtime  ^  0.100000 

Analysis  #  1 : 

Pzirse  Tree  =  s(np(comwall)  ,vp(vp(v(is))  ,vp(v(stonned)))) 
[cat :  s 

head:  [form:  finite 

trans:  [pred:  storm 

arg2:  cornHall]]] 


Number  of  Parses  =  1 
I :  Knights  sleep. 

Runtime  =  0.084000 

Analysis  #  1 : 

Parse  Tree  =  s(np(nom(knights)) ,vp(v (sleep))) 
[cat :  s 

head:  [form:  finite 

trans:  [pred:  sleep 
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argl:  Xnights] 
aux:  false]] 


Number  of  Parses  =  1 
I :  A  knight  storms  Comvall . 

Runtime  =  0.100000 

Analysis  #  1: 

Parse  Tree  =  s(np(det(a) ,nom(knight)) , 

vp(vp(v (storms))  ,np(comHall) ) ) 


[cat :  s 

head:  [form:  finite 

trans ;  [pred :  storm 
argl:  knight 
axg2:  cornHall] 
aux:  false]] 


Number  of  Parses  =  1 
I :  Other  storms  Comvall . 

Runtime  =  0.067000 

Analysis  0  1 : 

Parse  Tree  =  s(np(uther)  ,vp(vp(v(storms) )  ,np(comvall) )) 
[cat:  s 

head:  [form:  finite 

trans:  [pred:  storm 
argl;  uther 
arg2:  comvall] 
aux:  false]] 


Number  of  Parses  =  1 
I:  Uther  sleep. 

Runtime  =  0.050000 
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***  Cannot  parse  [uther .sleep] 

I ;  A  knights  storm  Comwall . 

Runtime  =  0,050000 

Cannot  parse  [a, knights .storm, Cornwall] 
h  -D 
yes 

I  ?-  halt. 

•  C  End  of  Prolog  execution  ] 
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B  Sample  Grammar  and  Prolog  DCG 


Demonstration  Grammar 

(adapted  from  Sample  Grammar  4  in  Shieber's  book  on  unification  El4] ) 

Includes  subject-verb  agreement 

complex  subcategorization 
logical-form  construction 
lexical  organization  by  templates 
and  lexical  rules 


Parameter:  Start  Symbol  is  S. 

Parameter:  Attribute  order  is  cat  lex  sense  head 

BUbcat  first  rest 
form  agreement  person 
number  gender 
trans  pred  argl  arg2. 


Grammar  Rules 


Rule  {sentence  formation} 

S  ->  HP  VP: 

<S  head>  =  <VP  head> 

<S  head  fom>  =  finite 
<VP  subcat  firBt>  =  <HP> 
<VP  subcat  rest>  =  end. 

Rule  {np  formation} 

HP  ->  Det  Horn: 

<HP  head>  =  <Det  head> 
<HP  head>  =  <Hom  Head>. 

Rule  {plirral  nouns} 

Det  ->  : 


<Det  head  agreement  number>  ^  plural.  ' 
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Rule  {trivial  verb  phrase} 


VP  ->  V: 


<VP  head>  =  <V  head>  ■ 

<VP  subcat>  =  <V  subcat>. 

Rule  {complements} 

VP_1  ->  VP_2  X: 

<VP_1  head>  =  <VP_2  head> 

<VP_2  subcat  first>  =  <VP_1  subcat  fixst> 
<VP_2  subcat  rest  fixst>  =  <X> 

<VP_2  subcat  rest  rest>  =  <VP_1  subcat  rest>. 


Definitions 


Let  Verb  be  <cat>  “  v. 


Let  Finite  be. Verb 

<head  fonii>  =  finite. 


Let  Houfinite  be  Verb 

<bead  fonD>  =  nonfinite. 

Let  TbixdPerson  be  <subcat  first  head  agreement  persoD>  third. 

Let  Singular  be  <8ubcat  first  head  agreement  number>  =  singular. 

Let  Plural  be  <subcat  first  head  agreement  number>  ^  plural. 

Let  TbixdSing  be  Finite 

ThirdPerson 

Singular. 

Let  KainVerb  be  Verb 

<head  aux>  ^  false. 


Let  Transitive  be  KainVerb 

<Bubcat  first  cat>  =  HP 
<subcat  rest  first  cat>  =  HP 
<subcat  rest  rest>  =  end 

<head  trans  argl>  =  <subcat  first  head  trana> 
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<head  trans  arg2>  =  <subcat  rest  first  head  traiis>. 

Let  Intransitive  be  KainVerb 

<3ubcat  first  cat>  =  NP 
<subcat  rEEt>  =  end 

<head  trans  argl>  =  <3ubcat  first  head  trans>. 

Let  Raising  be  <subcat  first  cat>  =  NP 

<subcat  rest  first  cat>  =  VP 

<3ubcat  rest  first  subcat  rest>  =  end 

<subcat  rest  first  subcat  first>  =  Csubcat  fixEt> 

<3ubcat  rest  re3t>  =  end. 

Define  AgentlessFassive  as  <out  cat>  =  <in  cat> 

<out  subcat>  =  <in  subcat  rest> 

<out  head  agreement>  =  <iii  head  agreeiiient> 
<out  head  aur>  =  <in  head  aux> 

<out  head  tran3>  *=  <in  head  tran3> 

<out  head  forn>  =  passiveparticiple. 


Word  uther: 


<cat>  =  np 

<head  agreement  gender>  *=  masculine 
<head  agreement  person>  =  third 
<head  agreement  number >  =  singular 
<head  trane>  =  uther. 

Word  comsall: 

<cat>  =  np 

<head  agreement  person>  =  third 
<head  agreement  number>  =  singular 
<head  tran3>  »=  comsall. 

Word  knights: 

<cat>  “  nom 

<head  agreement  gender>  »  masculine 
<head  agreement  pGr3on>  »=  third 
<head  agreement  number>  °  plural 
<head  trans>  ^  knights. 
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Word  knight: 


<cat>  =  noB 

<head  agreement  gender>  =  jnaaculine 
<head  agreement  person>  =  third 
<head  agreement  nunber>  =  singular 
<head  trans>  =  knight. 

Word  a: 


<cat>  *=  det 

<head  agreement  nuiiber>  ^  singular. 


Word  sleeps: 

Intransitive  ThirdSing 
<head  trans  pred>  =  sleep. 

Word  sleep: 

Intransitive  Plural 
<head  trans  pred>  =  sleep. 

Word  storms: 

Transitive  ThirdSing 
<head  trans  pred>  =  storm. 

Word  stormed: 

Transitive  AgentlessPassive 
<bead  trans  pred>  =  storm. 

Word  is: 

Raising  ThirdSing 

<subcat  rest  iirst  head  forB>  =  passiveparticiple 
<head  trans>  =  <subcat  rest  first  head  trans>. 
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The  following  is  the  DCG  produced  by  P-PATR  for  the  foregoing  grammar: 


enBure.loadeclCpatr support) . 
start (s) . 

feature_order(iBain,  [cat  ;_6688 , lex: _6681  .sense :_6674 .head: _6660, 
subcat ;_6667] . 

[_6688 , _6681 ._6674. _6660 ,_6667] ) . 

f  eature_order  (he ad .  [f  ora :  _687 3 .  agr eem eiit :  _6880 .  trans ;  _6866 .  aui :  _6887]1 . 

[-6866 . _6873 . .6880 . ^6887] ) . 
ieature_ order (subcat . [f irst:_7024.rest:_703l] . 

[-7024, .7031]). 

f eature_order (first, [cat :_7148, lei: _7141, sense :_7134,head:_7l20, 
subcat :_7127] , 

L7148,_7141,_7134,_7120,_7127]). 
feature_ordcr(rest, [first:_7328,rest:_7335] , 

[_7328,_7335]). 

feature_order (agreement , [person: _7431, number :_7424,gender;_7438] , 

L7424,_7431,_7438]). 

feature_order (trans ,  [p(red:_7558,argl:_7S6S,arg2:_7572]  , 

L  7558.  _  7565,  _7572J). 

feature_order(argl, [pred:_7690,argl;_7697,arg2:_7704] , 
[_7690,_7697,_7704]). 

feature_ordcr(arg2,  [p(red:_7822,argl:_7829,arg2:_7836]  , 
[_7822,_7829,_7836]). 


null  ([cat:  det, 
lex;  .7973, 
sense:  .7978, 
head;  [form:  .8072, 

agreement:  [person:  .8117, 
number:  plural, 
gender:  .8127] , 
trans:  .8082, 
aui:  .8087]  , 
subcat:  .7988]). 

Ic  (  [cat :  np , 
lex;  .8231, 
sense:  .8236, 
head:  .8241, 
subcat :  .8246] , 

.8691 ,_8746,_8693)--> 
doen([cat:  vp, 

lex:  .8179, 
sense;  .8184, 
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he^d:  [form:  finite, 

agreement ;  _8491 , 
trans:  _8496, 
am;  _8501] , 

subcat:  [first:  [cat:  np, 

lex:  .8231, 
sense;  _8236, 
head:  „8241, 
Bubcat:  _8246]  , 
rest:  end]]  , 

-8686) , 
lc([cat:  s, 

lex:  _8283, 
sense:  _8288, 
head:  [form:  finite, 

agreement:  _8491, 
trans:  _8496, 
aux:  _8501]  , 
subcat :  _8298] , 
_8691,b(_8746,_8686)  ._8693) . 

lc([cat:  det, 
lex;  _8855, 
sense:  _8860, 
head:  _8813, 
subcat:  _8870] , 
_9156,_9211,_9158)--> 
doyn([cat;  nom, 

lex:  _8803, 
sense:  _8808, 
head:  _8813, 
subcat:  _8818]  , 

-9151)  , 
lc([cat;  np, 
lex:  _8907, 
sense:  _8912, 
head:  _8813, 
subcat:  _8922]. 
_9156,np(_9211,_9151) ,_9158) , 

lc([cat:  nom, 
lex:  _8803, 
sense:  _8808, 
head:  [form:  _9261, 

agreement:  [person:  _9267, 
number:  plural, 
gender:  _9269] , 
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trans;  _9259, 
aui:  _9271J, 
subcat:  _8818] , 
_9283,_9338,_9285)— > 
lc([cat:  np, 

lei:  _8g07, 
sense:  _8912, 
head:  [fona:  _9261, 

agreement:  [person:  _9267, 
nunber;  plural, 
gender:  _9269] , 
trans:  _9259, 
aui:  _9271] , 
subcat:  _8922] , 
_9283,np(_9338)._9285). 

lc([cat;  V, 

lex:  _9394, 
sens?:  _9399, 
head;  _9404, 
subcat :  _9409J  , 

_9687 , _9742 , _9689) — > 
lc([cat;  rp, 
lei:  _9446. 
sense:  _9451, 
head:  _9404, 
subcat :  _9409]  , 

_9687.vp(_9742) ,_9689) . 

lc{[cat:  vp, 

lei:  _9798, 

sense;  _9803, 

head;  _9808, 

subcat:  [first:  _10053, 

rest:  [first;  _286, 
rest; 

_10472,_10527,_10474)“-> 
doTO(_286,_10467), 
lc(£cat:  vp, 
lei:  _98S0, 
sense:  _9855, 
head:  _9808, 
subcat :  [first :  _10053 , 
rest:  _101413], 

_10472,vp(_10527,_10467) ,_10474) . 
lei (uther , [cat :  np , 
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lex:  uther, 
sense:  uthcrl, 
head:  Cionn:  _  10838, 

agreement:  [person:  third, 

number:  singular, 
gender:  masculine], 
trans;  uther, 
aux:  _1084S] , 
subcat :  _10850] ) . 

lex(com«all,  [cat:  np, 

lex:  corneall, 
sense:  comvalll, 
head;  [form:  _10838, 

agreement:  [person:  third, 

number ;  singular , 
gender:  _10846] , 
trans :  comeall , 
aux:  _10848] , 
subcat:  „10850]). 

lex (knights , [cat :  nom , 

lex:  kni^ts, 
sense:  knightsl, 
head:  [form;  _10838, 

agreement:  [person:  third, 
number:  plural, 
gender:  masculine]  , 
trans:  knights, 
aux;  _ 10848] , 
subcat:  _10850]). 

lex(knight, [cat:  nom, 

lex;  knight, 
sense;  kni^tl, 
head:  [form:  _10838, 

agreement:  [person:  third, 

number:  singular, 
gender:  masculine]  , 
trans ;  knight , 
aux:  _10848]  , 
subcat:  _10850]). 

lex(a,[cat:  det, 
lex:  a, 
sense :  al , 

head:  [form:  _10838, 
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agreement:  [person:  _10844, 

number:  singular, 
gender:  _10846] , 
trans:  _10836, 
aux:  .10848], 
subcat:  .10850]). 

lezCsleeps , [cat :  v, 

lex:  sleeps, 
sense;  sleepsl, 
head:  [form:  finite, 

agreement:  .10846, 
trans:  [pred:  sleep, 
argl:  .10840, 
arg2:  .10842], 
aux:  false], 

subcat:  [first:  [cat:  np, 

lex:  .10966, 
sense:  .10964, 
head;  [form:  .10956, 

agreement;  [person:  third, 

number :  singular , 
gender:  .11322] , 
trans:  .10840, 
aui:  .10960] , 
subcat:  .10962], 
rest:  end]]) . 


lexCsleep, [cat:  v, 

lex:  sleep, 
sense:  sleepl, 
head:  [form:  .10844, 

agreement:  .10846, 
trans:  [pred:  sleep, 
argl:  .10840, 
arg2:  .10842], 
aux:  false], 

subcat:  [first:  [cat;  np, 

lex:  .10966, 
sense:  .10964, 
head:  [form:  .10956, 

agreement:  [person:  .11170, 
number :  plural , 
gender;  .11172], 
trans:  .10840, 
aux:  .10960] , 
subcat:  .10962] , 


50 


rest;  end]]). 


lex(storms , [cat :  v, 

lex;  storms, 
sense;  stormsl, 
head;  [form;  finite, 

agreement;  _10846, 
trans;  [pred:  storm, 
argl:  _10840, 
arg2;  .10842], 
aux:  false], 

subcat [first :  [cat:  np, 

lex;  .10966, 
sense:  .10964, 
head:  [form;  .10956, 

agreement:  [person:  third, 

number:  singular 
gender:  .11366]  , 
trans;  .10840, 
aux:  .10960], 
subcat :  .10962] , 
rest:  [first:  [cat:  np, 

lex:  .10988, 
sense:  .10986, 
head:  [form:  .10978, 

agreement:  .10980, 
trans:  .10842, 
aux;  .10982], 
subcat:  .10984], 
rest :  end]  ]  ]  )  . 


lex (stormed, [cat :  t, 

lex:  .10854, 
sense:  .10852, 

head:  [form:  passiveparticiple, 
agreement:  .10846, 
trans:  [pred:  storm, 
argl:  .10840, 
arg2:  .10842], 
aux:  false], 

subcat:  [first:  [cat:  np, 

lex:  .10988, 
sense:  .10986, 
head;  [form;  .10978, 

agreement:  .10980, 
trans:  .10842, 
aux:  .10982] , 
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subcat;  _10984] , 
rest:  end!]]). 


lex(is,[cat:  v, 
lex:  is, 
sense:  isl, 
head: 

[fom:  finite, 
agreement:  _10840, 
trans:  _10836, 
aux:  _10842], 
subcat : 

Efirst: 

[cat:  np, 
lex:  _10984, 
sense:  _10982, 
head: 

[form:  _11256, 
agreement: 

[person:  third, 
number:  singular, 
gender:  _11264] , 
trans:  _11254, 
aux:  _11266], 
subcat :  _10980] , 
rest: 

[f  irst : 

[cat:  vp, 
lex:  _10866, 
sense:  _10864, 
head; 

[form:  passiveparticiple, 
agreement:  _10858, 
trans:  _10836, 
aux:  _10860] , 
subcat : 

[first: 

[cat:  np, 
lex:  .10984, 
sense:  .10982, 
head: 

[form:  .11256, 
agreement : 
[person:third, 
number:  singular, 
gender:  .11264], 
trans:  .11254, 
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aux:  _11266], 
Eubcat:  _10980]  , 
rest :  end]  ]  , 
rest ;  end]  ]  ]  )  . 
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C  Selected  Code 


’/.  Module:  COMPILEPATR.PL 
y.  Author:  Susan  B.  Hirsh 

7.  Purpose:  Conplle  a  clausal  iora  of  a  PATH- II  granunar  into  a 
7.  DCG. 

7<  load  all  supplemental  nodules 

:-  ensure_loaded(  readrules  ) .  %  read  in  PATB-II  rules 

:-  ensure_loaded  (  parameters  ).  7.  handle  parameter  statements 

:-  ensure_loaded(  paths  ).  X  generate  feature  information 

ensure_loaded(  epsilons  )•  '!•  precompile  epsilon  rules 

ensur e_ loaded (  compilegrammar  ).  7#  compile  the  PATR-II  grammar 
ensure_loaded(  unify  ).  7  unify  PATR-II  equations 

ensure_loaded(  compilelex  ).  7  precompile  lexical  entries 


7<  External  predicates  : 

7. 

7. 

7.  Module  CDMPILEGRAMMAR.pl  - 

7. 

7.  compile_gramjaar/3  - 

7,  compile  PATR-II  grammar  into  a  DCG. 

% 

7. 

7.  Module  CQMPILELE1.pl 

7. 

7.  compile_lex/l  - 

X  execute  each  lexical  entry  in  the  database. 
7. 

7 

7  Module  EPSILDHS.PL 

7. 

7  epBilons/2  - 

7  precompile  epsilon  rules. 

7 

7. 

7  Module  PARAMETERS.pl 

7. 

X  parameter/3  - 

7  process  all  parameter  statements. 

7. 

7. 
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X  Module  PATHS.pl 

7. 

7.  patbs/2  - 

X  generate  all  feature  information. 

X 

X 

X  Module  PATRLIBRARY.pl 
X 

X  file_name/3  - 

X  create  a  nev  file  name  sith  a  nee  ending. 

X  Brite_clause/2  - 

X  write  clause  to  output  stream  in  Prolog  clause  format. 

X 

X 

X  Module  PATRSUPPORT.pl 
X 

X  foraat_stats/0  - 
X  output  statistics  on  runtime. 

X  Bet_timer/0  - 
X  reset  runtime  timer. 

X 

X 

7.  Module  HEADRULES.pl 
X 

X  input_rules/2  - 

X  Read  in  PATR-II  rules  from  .PTRP  file. 


X 

X  compilepatr(  File  ) 

X 

X  Input  : 

X  File  -  name  of  input  file  (must  have  .PTRP  extension) 

X 

X 

X  Take  a  list  of  PATR-II  rules  produced  by  READPATR.PL  and 
X  convert  them  into  a  definite-clause  grammar  (DCG) . 


conpilepatr(  File  ) 

format (  ’*nCoBq)iling  ..."n’,  □  ), 
input _rules(  File,  Rules  ), 
output_rules (  File ,  Rules  )  . 


X  output  current  status 
X  read  in  grammar  rules 
X  convert  rules  to  DCG 
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7. 

%  output_rul€3(  File,  Rules  ) 

7. 


7  Input  ; 

7  File  -  n^lne  of  input  file 
7  Rules  -  list  of  PATR-II  rules 
7 

7. 

7  Convert  PATR-II  rules  into  a  DCG  and  output  the  DCG. 


output_rule3C  File,  Rules  ) 

file_najae(  File,  ".deg"  ,  Output  ),  7,  output  file  is  File, deg 

open(  Output,  write,  OutStrean  ),  7  open  output  file 

7  insert  line  into  DCG  to  include  runtime  support 
write^clause (  (  ensure_loadedC  patrsupport  )  ), 

OutStream  ) , 

conpile_rules(  Rules,  OutStreais  ),  7  compile  PATR-II  rules 

clo3e(  OutStrean  ),  7,  close  output  file 

(  load_parser(  yes  )  ->  7  is  DCG  to  be  loaded 

load_dcg(  Output  )  7  load  the  DCG 

I  true  ) .  7,  do  nothing 


7 

7  coDpile_rules(  Rules,  OutStrean  ) 

7 

7  Input  : 

7  Rules  -  list  of  PATR-II  rules 
7  OutStrean  -  ciirrent  output  stream 
7 
7 

7  Compile  PATR-II  rules  into  a  DCG. 


conpile_rules(  Rules,  OutStrean  )  :- 

set^tiner,  7  set  runtime  timer 

parameterC  Rules,  OnljRules,  OutStrean  ),  7  handle  parameters 
paths (  OnlyRules,  OutStrean  ) ,  7  get  feature  information 

7  preconpile  epsilon  rules 
epsilons  (  DnlyRtHes ,  OutStre  an  )  , 

compile_granmar(  OnlyRules,  Rules,  OutStrean  ),7  make  DCG 
7  execute  lexical  entries 
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coBpile_lex(  OutStrean  ) , 
f  onnat.stats . 


%  output  compile  statistics 


7. 

7.  load_dcg(  Output  ) 

7. 

7.  Input  : 

7.  Output  -  name  ol  output  file 
7. 


7. 


7,  Load  DCG  into  Prolog  database. 


load_dcg(  Output  ) 

fonaat(  '"nLoading  ...~n*,D  )  output  current  status  - 
enBurc_loadGd(  Output  ) . 
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%  Module:  COHPILEPATR.PL 
X  Submodule;  READRULES.PL 
X  Author:  Susan  B.  Hirsh 
X  Purpose:  Read  in  a  list  of  PATH  rules. 


X  External  predicates  : 

7. 

X 

%  Module  PATRLIBRARr.PL 

X' 

X  file_aaae/3  - 

X  create  a  new  file  name  oith  a  nee  ending. 


X- 


X 

X  input _rules(  File,  Rules  ) 
X 


X  Input  : 

X  File  -  input  file  name 

X 


X  Output  : 

X  Rules  -  list  of  all  PATR-II  rules  from  input  file 

X 

X 

X  Read  in  PATR-II  rules  from  input  file  and  put  into  a  list. 


input .rules (  File,  Rules  )  :- 
seeingC  Infile  ), 
file_name(  File,  ".ptrp".  Input 
Bee(  Input  ) , 
read_rules(  Rules  ), 
seen, 

see(  Infile  ) . 


X  save  current  input  file 
),  X  input  file  is  File. ptrp 
X  open  input  file 
X  read  in  the  rules 
X  close  input  file 
X  restore  input  file 


*x 

X  read_rules(  Rules  ) 

X 

X  Output  : 

X  Rules  -  list  of  PATR-II  rules 
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7. 

X  Read  in  a  list  of  PATR-II  rules. 


read_rulea(  Rules  ) 

read(  Rule  ),  .  7.  read  in  the  first  rule 

read_Biore^rules(  Rule,  Rules  ).  7.  read  in  the  rest 


X - 

7. 

X  read_nore_rules(  PreviousRules ,  NeuRules  ) 

X 

X  Input  : 

X  PreviousRules  -  list  of  PATR-Il  rules  as  it  is  being 
X  built  up 

X 

X  Output  ; 

X  KewRules  -  list  of  PATR-II  rules 
X 

X  Read  in  a  list  of  PATR-II  rules. 


X  stop  at  the  end  of  the  file 
read_inore_Tules  (  end_of _f ile 


X  ieep  reading  until  the  end  of  the  file 
read_more_rule3(  Rule,[  Rule  I  Rules  ]  )  :- 

readC  NevRule  ) ,  X  read  in  a  PATR-II  rule 

read_inore_xules(  KesRule,  Rules  ).  X  read  in  the  rest 
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7.  Module:  COMPILEPATR.PL 
7.  Subaodule;  PARAMETERS. PL 
7  Author:  Susan  B.  Hirsh 

%  Purpose:  Record  the  infomation  Iron  the  parameter  statements. 


X  External  predicates  : 

X 

X 

X  Module  PATRUBRARY.pl 
X 

X  write_clau3e/2  - 

X  vrite  clause  to  output  stream  in  Prolog  clause  iormat. 


X 

2  parameter(  Rules,  NesRules  ) 

X 

X  Input  : 

X  Rules  -  list  of  PATR-II  rules 

X 

X  Output : 

X  NenRules  -  list  of  PATR~II  rules  minus  parameter  statements 

X 

X 

X  Handle  parameter  statements  first,  as  they  lomt  appear  only  at 
X  the  top  of  the  file. 

X  handle  start  symbol 

parameter(  [  parameterC  start(  Symbol  )  )  I  Rules  ],  NesRules, 
OutStream  ) 

assert(  start (Symbol)  ),  X  assert  start  symbol 

urite.clause  (  (  start  (Symbol)  ),  OutStream  ),  X  wite  to  output 
parameter (  Rules,  HeuRules,  OutStream  ).  X  handle  others 

X  keep  track  of  attribute  order 

parameter(  [  parameter (  attributes  (  List  )  )  1  Rules  ],  HesRules, 
OutStream  ):- 
X  record  the  correct  order 
record. order (  List,  1  ), 

X  handle  other  parameter  stmnts 
parameter (  Rules,  NesRules,  OutStream). 
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y,  ignore  restrictor 

paraiiieter(  [  paraneterC  restrictorC  .List  )  )  I  Rules  ]  ,  HenRules, 
OutStrean  )  :- 

paraneterC  Rules,  NesRules,  OutStrean  }. 

X  ignore  translation 

paraneterC  [  paraneterC  translationC  .List  )  )  I  Rules  ],  NevRules, 
OutStrean  ) 

paraneterC  Rules,  NevRules,  OutStrean 

X  no  more  paraneter  statenents  -  return  list  minus  parameters 
paraneterC  Rules,  Rules,  .OutStrean  ). 


%  record.orderC  Attributes,  Place  ) 

X 

X  Input  : 

X  Attributes  -  list  of  attributes  in  the  order  in  which  they 
X  are  to  appear 

X  Place  -  position  in  the  list  of  the  current  attribute 

X 

X 

X  Record  the  print  order  of  each  attribute. 


X  record  the  position  of  each  attribute 
record.orderC  [  Attribute  I  Attributes  ]  ,  Place  ) 
X  assert  for  use  in  printing 
assert C  print.orderCAttribute, Place)  ), 

X  increment  position 
NevPlace  is  Place  +  1 , 

X  go  on  to  the  next  attribute 
record.orderC  Attributes,  NeoPlace  ). 

X  no  store  attributes 
record.orderC  □  ,  .Place  ) . 
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%  Module:  CDHPILEPATR.PL 
•/.  Submodule:  PATHS. PL 
X  Author:  Susan  B.  Hirsh 

X  Purpose:  Compile  all  information  on  position  and  order  of 
X  the  features . 


X  External  predicates  : 

X 

X 

X  Module  PATRLIBRARY.pl 
X 

X  ¥rite_clause/2  - 

X  urite  clause  to  output  stream  in  Prolog  clause  format. 

X 

X 

X  Module  PATRSUPPORT.pl 
X 

X  print _order/2  - 

X  the  printing  order  of  this  feature  in  the  feature  structure. 


X 

X  paths (  Rules,  OutStream  ) 

X 

X  Input  : 

X  Rules  -  list  of  PATR-II  rules 
X  OutStream  -  current  output  stream 
X 
X 

X  Generate  for  each  attribute  a  list  of  the  features  that  can 
X  follov  it  eind  assert  this  information  into  the  data  base 
X  and  output  into  output  file. 

X 

X  For  example  : 

X 

X  The  rule 

X  rule(NP,  [N]  ,  [[llP,cat]=np,  [N,cat]=n,  [HP .body] =[N .body]]) 

X 

X  vould  produce  the  list  : 

X  feature_order(nain,  [cat :I, body: Y],  [X,Y]) 

X 

X  where  the  attribute  'main’  is  a  dinmny  attribute  used  to  designate 
X  that  a  feature  following  it  was  the  first  feattu:e  in  a  path 
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7.  specification. 


paths (  Rules,  OutStream  ) 

7,  create  lists  of  Vars,  Bindings,  and  Pairs 

type_info(  Rules,  [  Main  ],  Types,  [  nain=Main  ],  Bindings,  □, 
Pairs  ) , 

calc_types(  Pairs  ),  7.  make  pairs  into  paths 

tails  (  Types  ),  7.  get  rid  of  tail  variables 

7,  assert  paths  into  database  and  erite  into  output  file 
output_path3 (  Bindings,  OutStream  ). 


X - 

7. 

%  type_info(  Rules,  OldTypes,  Types,  OldBindings, -Bindings, 

7,  OldPaths,  Paths  ) 

7. 

7.  Input  : 

%  Rules  -  list  of  rules  in  PATR-II  format 
7  OldTypes  -  types  found  so  far 
X  OldBindings  -  bindings  found  so  far 
X  OldPaths  -  paths  found  so  far 
1 

7,  Output  : 

X  Types  -  list  of  types 
X  Bindings  -  list  of  bindings 
X  Paths  -  list  of  paths 

X 

X 

X  Extract  from  each  rule  the  features  used  in  that  rule.  From 
X  this  feature  information  compile  three  different  lists  : 

7. 

X  Types  ;  a  list  of  vatriables  associated  eith  the  features 
X  Bindings  :  a  list  containing  information  as  to  ehich  attributes 
X  are  bound  to  shich  variables. 

X  Pairs  :  a  list  specifying  which  features  can  follow  which  others 


X  no  more  rules 

type_info(  □,  Types,  Types,  Bindings,  Bindings,  Peiirs,  Pairs  ). 

X  extract  info  from  each  rule 

type_info(  [  Rule  1  Rules  ],  Types,  Rtypes,  Bindings,  Rbindings, 
Pairs,  Rpairs):- 

X  features  are  contained  in  the  unification  equations  of  a  rule 
unifsC  Rule,  Unifs,  Type  ),  X  get  feature  information 
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y.  process  the  iesture  inf onaation 

info<  Type,  Unils ,  Types,  Ntypes,  Bindings,  Nbindings,  Pairs, 
Hpairs  ) , 

■/,  do  the  rest  of  the  rules 

type_info(  Rules,  Ntypes,  Rtypes,  Nbindings,  Rbindings,  Npairs, 
Rpairs) . 


X - - 

y. 

X  unifs(  R\ile,  Unifs,  Type  ) 

y. 

y.  Input  : 

y.  R\ile  -  current  PATR-II  rule 
y.  Type  -  what  kind  of  rule  this  is 

y. 

‘L  Output  : 

y,  Unifs  -  list  of  unifications  for  that  rule 

y. 

y. 

'J,  Extract  the  unification  equations  from  the  rule. 


y.  gramnar  rule 

unifs (  rule(_Lha,_Rhs,Unifs) ,  Unifs,  lule  ). 

%  lexical  entry 

unlfsC  lex(_Vord,Unifs) ,  Unifs,  lex  ). 

%  lexiceO.  template 

tmifs(  template(_NaBe, Unifs)  ,  Unifs,  lex  ). 

%  lexical  rule 

unifsC  lex_rule(_Name, _InFS,_OutFS, Unifs) ,  Unifs,  rule  ). 


y,  info(  Type,  Unifs,  OldTypes,  Types,  OldBindings,  Bindings, 
%  DldPaths,  Paths  ) 

y. 

y.  Input  : 

%  Type  -  the  type  of  rule  it  is 
X  Unifs  -  list  of  t(nif ications  for  that  rule 
X  QldTypes  -  list  of  types  so  far 
X  OldBindings  -  list  of  bindings  so  far 
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%  OldPaths  -  list  of  paths  so  far 

X 

X  Output  ; 

X  Types  -  list  of  types 
X  Bindings  -  list  of  bindings 
X  Paths  -  list  of  paths 

X 

X 

X  Extract  feature  inforoation  fron  the  unification  equations. 


X  no  more  unifications  in  this  rule 

info(  ^All,  □,  Types,  Types,  Bindings,  Bindings,  Pairs, 

Pairs  ). 

X  ignore  template  and  lexical  rule  names,  as  these  features  are 
X  handled  in  template  or  rule  definitions 

infoC  Kind,  [  Templatel  T  ],  Types,  Rtypes,  Bindings,-  Rbindings, 
Pairs,  Rpairs) 

atomic (  Template  ),  !,  X  this  is  a  template  or  lexical  rule 

X  go  on  to  the  next  unification  equation 

info(  Kind,  T,  Types,  Rtypes,  Bindings,  Rbindings,  Pairs, 

Rpairs  ) . 

X  for  rules  : 

X  handle  unifications  of  the  form  :  Pathl  =  Path2 
X  E.G. , 

X  <S  head>  <VP  head> 

info(  rule,  [  [  _Varl  I  Featuresl  ]  = 

[  _Var2  I  Features2  ]  I  T  1 , 

Types,  Rtypes,  Bindings,  Rbindings,  Pairs,  Rpairs  ) 

X  unify  the  final  feature  values  so  that  paths  can  unify 
add_paths(  Featuresl,  Types,  Rtypes,  Bindings,  Rbindings,  Pairs, 
Rpairs,  main.  Last), 

add_path5(  Features2,  Rtypes,  Htypes,  Rbindings,  Hbindings, 
Rpairs,  Hpairs,  main.  Last  ), 

X  go  on  to  the  next  unification  equation 

info(  rule,  T,  Htypes,  Rtypes,  Hbindings,  Rbindings,  Hpairs, 
Rpairs  ) . 

X  handle  unifications  of  the  form  :  Path  =  val 
X  E.G., 

X  <X  cat>  =  np 

info(  rule,  [  [  _Var  I  Features  ]=Atom  I  T  3,  Types,  Rtypes, 
Bindings,  Rbindings,  Pairs,  Rpairs  ) 
atomic (  Atom  ), 
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'/,  add  ieatiire  information 

add_paths(  Features,  Types,  Ntypes,  Bindings,  Hbindings,  Pairs, 
Npairs,  main,  _Last) , 

*/,  go  on  to  next  unification 

info(  rule,  T,  Ntypes,  Rtypes,  Nbindings,  Rbindings,  Npairs, 
Rpairs  ) . 

for  lexical  entries  or  templates  : 

y,  handle  unifications  of  the  form  :  Path  =  val 
‘/.  E.G., 

7.  <cat>  =  np 

info(  lex,  [  Features=AtoB  IT  J.  Types,  Rtypes,  Bindings, 

Rbindings,  Pairs,  Rpairs) 
atomic (  Atom  ) , ! , 

7,  add  feature  information 

add_paths(  Features,  Types,  Ntypes,  Bindings,  Nbindings,  Pairs, 
Npairs,  main.  _Last  ), 

7,  go  on  to  next  unification 

info(  lex,  T,  Ntypes,  Rtypes,  Hbindings,  Rbindings,  Npairs, 
Rpairs  ). 

'L  handle  unifications  of  the  form  :  Fathl  =  Path2 
7.  E.G., 

7.  <head>  =  <head> 

info(  lex,  [  Featuresl»=FeatTircs2  |  T  ],  Types,  Rtypes,  Bindings, 
Rbindings,  Pairs,  Rpairs  ) 

7,  unify  the  final  feature  values  so  that  paths  can  unify 
add_paths(  Featuresl ,  Types,  Ntypes,  Bindings,  Nbindings,  Fairs, 
Npairs,  mean,  Last  ), 

add_paths(  Features2,  Ntypes,  Mtypes,  Nbindings,  Hbindings, 
Npairs,  Mpairs,  maih.  Last  ), 

info(  lex,  T,  Htypes,  Rtypes,  Hbindings,  Rbindings,  Hpairs, 
Rpairs) . 


X - 

1 

7.  add_paths(  Features,  OldTpes,  Types,  OldBindings,  Bindings, 
7.  Oldpairs,  Pairs,  Place,  Last  ) 

% 

X  Input  : 

%  Features  -  list  of  features  in  one  unification  equation 

X  OldTypes  -  list  of  types  so  far 

7,  OldBindings  -  list  of  bindings  so  far 
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X  DldPairs  -  list  of  pairs  so  far 
X  Place  -  previous  feature 

X  Last  -  Var  value  of  last  feature  on  the  list 

X 

X  Output  : 

X  T3rpes  -  list,  of  tsrpes 
X  Bindings  -  list  of  bindings 
X  Pairs  -  list  of  pairs 

X 

X  Create  the  three  list  of  T3rpes,  Bindings  and  Pairs  as  described. 

X  last  feature,  just  return  variable  for  later  unifications 
add.pathsC  □,  T3rpes,  Types,  Bindings,  Bindings,  Pairs,  Pairs, 

Place,  Last  );- 

X  get  variable  equivalence  of  this  attribute 
searchC  Place,  Bindings,  Last  ). 

X  add  on  the  Types,  Bindings  and  Pairs 

add_paths(  [  Feature  I  Features  ],  Types,  Rtjrpes,  Bindings, 

Rbindings,  Pairs,  Rpairs,  Place,  Last  ) 

X  get  variable  value 

searchC  Place,  Bindings,  Var  ), 

X  get  Type  and  Binding  information 

checkpatbsC  Feature,  Tsrpes,  Nt3rpes,  Bindings,  Nbindings  ), 

X  get  pair  information 

add.pairsC  Var,  Feature,  Pairs,  Npairs  ), 

X  handle  next  attribute 

add_paths(  Features,  Ntypes,  Rtypes,  Nbindings,  Rbindings,  Npairs, 
Rpairs ,  Feature ,  Last  ) . 


I - 

X 

X  searchC  Place,  Bindings,  Var  ) 

X 

X  Input  : 

X  Place  -  current  attribute  to  look  up 
X  Bindings  -  list  of  bindings 
X 

X  Output  : 

X  Var  -  Prolog  Var  value  of  the  attribute 

X 

X 

X  Look  up  the  Var  value  of  the  current  attribute  on  the  Bindings 
X  list. 
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%  stop  vhen  you  find  the  attribute 

searchC  Place,  [  Placc=Var  I  _Bindings  ],  Var  ) 

'L  keep  searching  until  you  find  it 
searchC  Place,  [  _Binding  I  Bindings  ],  Var  ) 
searchC  Place,  Bindings,  Var  ). 


X - 

% 

%  checkpathsC  Feature,  Oldtypes,  Types,  Oldbindings,  Bindings  ) 

X 

X  Input  : 

X  Feature  -  current  attribute 
X  DldTypes  -  list  of  types 
X  DldBindings  -  list  of  bindings 

X 

X  Output  ; 

X  Types  -  neo  list  of  types  if  attribute  eas  added 
X  Bindings  -  nee  list  of  bindings  if  attribute  oas  added 

X 

X 

X  Check  if  an  attribute  is  bound  in  the  Bindings  list  and  add  it 
X  if  it  isn’t  already  there. 

X  add  attribute  if  it  is  not  there 
checkpathsC  Feattire,  Types,  [  Var  I  Types  ],  □, 

[  Feature>»Var  D  ) . 

X  if  it  is  there,  do  nothing 

checkpathsC  Feature,  Types,  Types,  [  Feature=Var  i  Bindings  ], 

[  Feature=Var  I  Bindings  ]  )  ! . 

X  if  it  is  not  there,  keep  trying  the  rest  of  the  list 
checkpathsC  Feature,  Types,  Btypes,  [  Binding  I  Bindings  D, 

[  Binding  |  Rbindings  ]  ) 

checkpathsC  Feature,  Types,  Rtypes,  Bindings,  Rbindings  ). 


5; - 

X  add_pairsC  Var,  Feature,  OldPairs,  Fairs  ) 
X 
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y.  Input  : 

y,  Var  -  var  to  add 
X  Feature  -  attribute  to  add 
y,  QldPairs  -  previous  list  of  pairs 

y. 

'/.  Output  : 

X  Pairs  -  neo  list  of  pairs 

X 

X  Add  a  Var  and  a  Feature  to  Pairs  list. 


add_pairs(  Var,  Feature,  Pairs,  L  Var  :  Feature  I  Pairs  ]  ). 


X 

X  calc_types(  Pairs  ) 

X 

X  Input  ; 

y.  Pairs  -  list  of  pairs 

X 

X 

X  Once  all  of  the  Pairs  have  been  done,  go  throught  the  Pairs  list 
X  and  add  all  pairs  to  the  one  preceding  them. 

X 

X  For  example  : 

X  Pairs  Bill  look  like  [CAthead]  .  [A,cat!]] 

X  and  noB  A  Bill  look  like  Qiead,catl 


X  add  pair  to  list 

calc_types(  [Type  :  Label  I  Pairs]  ):- 

insert (  Label,  Type  ),  X  unify  it  into  the  Prolog  variable 
calc_typeB(  Pairs  ).  X  go  to  next  pair 

y,  no  more  pairs 
calc_types(  D  )• 


X  insert (  Feature,  Variable  ) 

X 

X  Input  : 

X  Feature  -  current  attribute 
X  Variable  -  variable  to  insert  value  into 
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•/. 

•/. 

X  Unify  a  feature  into  the  Prolog  variable  if  it  is  not  already 
X  there. 


X  it  is  already  there,  do  nothing 
insertC  Label,  [  Label  i  . 

X  Unify  feature  into  variable 
insert (  Label,  [  _  I  Labels  ]  )  :- 
insert (  Label ,  Labels  ) . 


X - 

X 

X  tails (  Types  ) 

X 

X  Input  : 

X  Types  -  list  of  types 

X 

X  Change  all  tail  variables  that  are  sideeffects  of  Insert 
X  to  □. 


X  change  tail  variable  to  0 
tails (  Var  ) 

var(  Var  ) ,  ! ,  X  this  is  a  tail  variable 

Var  *=  0. 

X  not  a  list,  do  nothing 
tails (  Atom  ) 

atomicC  Atom  ) ,  ! . 

X  check  all  internal  lists 
tails (  [  Head  I  Tail  ]  )  ;- 

tails (  Head  ),  X  process  first  list 

tails (  Tail  ).  X  process  the  rest  of  the  list 

tails  (  □  ). 


X  output _paths(  Bindings  ) 
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•/. 

%  Input  : 

Bindings  ~  list  that  nov  has  a  ieatuxe  and  all  the  leatuxes 
X  that  can  iollov  it 

7. 

7. 

%  Go  through  the  list  of  bindings  that  nov  have  all  features  in 
X  the  variable  and  create  paths. 

X  For  example  : 

X  Bindings  will  be  main^ [head, cat] 

X  Path  is  [main,  [head: A, cat: B]  ,  [A, B]] 


X  no  more  in  bindings  list 
output_paths  (  [],  _0ut  Stream  ). 

X  make  paths  for  all  bindings 

output_path3(  [  Binding  I  Bindings  ] ,  OutStream  ) 

maJce_path(  Binding,  OutStream),  X  ma^e  the  path 

output_paths (  Bindings ,  OutStream  ) .  X  go  to  next  binding 


X 

X  make.pathC  Feature,  OutStream  ) 

X 


X  Input  : 

X  Feature  -  a  feature  and  list  of  features  that  can  follow  it 
X  OutStream  -  current  output  stream 

X 

X 


X  Change  path  into  Prolog  variables  and  then  eissext  and  output. 


X  feature  cannot  be  followed 
make_path(  _Head=n ,  _OutStream  ). 

X  process  this  path 

make.pathC  Head=Featuxes,  OutStream  ) 

X  change  path  into  variables 

change (  Head,  Features,  LabelList,  VarList  ), 

X  assert  and  output 

write_path(  Head,  LabelList,  VarList,  OutStream  ). 
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X - 

•/. 

*/,  change (  Head,  Features,  LabelList,  VarList  ) 

•/. 

7,  Input  ; 

7  Head  -  starting  attribute 

7.  Features  -  list  ot  features  that  can  follow  Head 

7. 

7,  Output  : 

7.  LabelList  -  list  of  Prolog  variables  and  features  for  the  path 
7f  VarList  -  same  as  LabelList  with  no  attributes 

•/. 

7 

7  Put  path  into  Prolog  variables 
7  Take  binding 
7  main  -  [cat .head] 

7  and  make  the  lists  : 

7  LabelList  -  [cat:Cat,head:Head] 

7  VarList  -  [Cat, Head] 


7  no  more  paths 

changeC  _Head,  □,  □,  □  ). 

7  change  each  path 

changeC  Head,  [  Feature  I  Features  ],[  Feature  :  Var  I  Labels  ], 
[  Var  I  Vars  ]  )  :- 

changeC  Head,  Features,  Labels,  Vars  ). 


7  write_pathC  KaioFeature,  LabelList,  VarList,  DutStream  ) 
7 

7  Input  : 

7  MainFeature  -  feature  that  all  other  features  follow 
7  LabelList  -  list  of  attributes  and  variables 
7  VarList  -  same  as  LabelList  with  no  attributes 
7  OutStream  -  current  output  stream 
7 
7 

7  Output  path  as: 

7 

7  feature.orderCHainFeature,  LabelList,  VarList) 
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Brite_path(  Hain,  LabelList,  VarList .DutStream) 

'/,  reorder  the  list  into  printing  order 
reorder (  LabelList,  OrderLabelList  ), 

'/.  output  to  screen  trace  flag  is  on 
(trace_paths C  yes  )  -> 
foxaatC  ’Path  is  "B"n’, 

[  feature_order(Main, OrderLabelList, VarList)  ]  ) 

I  true  ), 

%  assert  into  database  for  use  during  compilation 
assertC  feature_order (Main, OrderLabelList, VarList)  ),!, 

7,  nrite  into  output  file  for  use  during  parse 
¥rite_clause( (feature_order (Main, OrderLabelList , VarList)) , 
OutStrean  ) . 


•i 

%  reorder (  PS,  NesFS  ) 

7. 

X  Input  : 

X  FS  -  feature  structure  to  be  reordered 

X 

X  Output  ; 

X  NeuFS  -  feature  structure  with  features  as  specified 

X 

7. 

X  Reorder  the  features  in  the  FS  according  to  the  order  given 
X  in  the  parameter  statement. 


reorder (  Pairs,  HesPairs  ) 

X  attach  the  order  in  which  they  should  appear 
number (  Pairs,  NuraberedPairs  ), 

keysort(  NumberedPairs ,  SortedPairs  ),  X  sort  by  position 
X  get  rid  of  position  numbers 
cleanC  SortedPairs,  NewPairs  ). 


X - 

X 

X  number(  FS,  NewFS  ) 


X 


X  Input  : 

X  FS  -  feature  structure  to  be  reordered 

X 
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’/  Output  : 

'/.  NeoFS  -  feature  structure  with  features  labeled  with 
7.  their  position  number 

7. 

7. 

7.  Attach  onto  each  feature  in  the  FS  the  position  number  specified. 


7.  number  each  feature 

numberC  C  Label  :  Value  I  Rest  ] , 

[  Position-(Label : Value)  I  NRest  ]  );- 
find_order(  Label,  Position  j,  7,  get  position  number 
numberC  Rest,  NRest  ).  7.  do  the  rest 

7.  no  more  features 
number  (  □  ,  []  )  . 


1- 

7. 


7.  find.orderC  Feature,  Position  ) 

7. 

7.  Input  : 

7.  Feature  -  feature  to  get  position  of 

7. 

X  Output  : 

7  Position  -  position  number  of  the  feature 

7. 

7. 

7.  Get  the  position  number  of  the  feature 


7,  order  was  specified 
find_orderC  Label,  Position  ) 

print_order(  Label,  Position  ),  !.  7,  specified  order 

7.  no  order  given,  affix  to  the  end 
find_order(  _Label,  9999  ). 


7. 

X  clean (  FS,  NewFS  ) 

X 

7.  Input  : 
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X  FS  -  feature  structure  with  feature  positions  attached 

y. 

y.  Output  : 

%  NeeFS  -  feature  structure  without  feature  positions 

y. 

y. 

y.  Remove  position  numbers  attached  to  the  features. 


y,  get  rid  of  position  number 
cleanC  [  _N- (Label: Value)  i  Nrest  ] , 
[  Label  :  Value  i  Rest  ]  ) 
clean (  Nrest,  Rest  ). 

y,  no  more  features 
cleanC  □,  □  ). 
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7.  Module:  COHPILEPATR.PL 
%  Submodule:  EPSILONS. PL 
7.  Author:  Susan  B.  Hirsh 
%  Purpose:  Preprocess  all  epsilon  rules. 


External  predicates  : 

X 

X 

%  Module  UNIFY.pl 
X 

X  apply _r\ile_unif s/1  - 

X  apply  the  unification  equations  for  a  grammar  or  lexical  rule. 

X 

7. 

X  Module  PATRLIBRARY.pl 

7. 

X  Brite_clau3e/2  - 

X  write  clause  to  output  stream  in  Prolog  clause  format. 


X - 

X 

X  epsilonsC  Rules,  NeeRules,  OutStream  ) 

X 

X  Input  : 

X  Rules  -  List  of  PATH-II  rules 
X  OutStream  -  current  output  stream 

X 

X  Output  : 

X  NewRules  -  List  of  PATR-II  rules  minus  epsilon  rules 

X 

X 

%  Precompile  epsilon  rules  for  use  in  compilation. 


X  no  more  rules 
epsilonsC  □,  _ OutStream  ). 

X  go  through  the  rules 

epsilonsC  [  Rule  I  Rules  ]  ,  OutStream  ) 

e_ruleC  Rule,  OutStream  ),  X  is  it  an  epsilon  rule? 

epsilonsC  Rules,  OutStream  ).  X  go  to  next  rule 
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•I- - 

•/. 

'L  e_rule(  Rule,  OutStream  ) 

y. 

X  Input  : 

•/.  Rule  -  PATR-II  rule 
X  OutStrean  -  current  output  stream 

X 

X 

X  Compile  the  epsilon  rule  into  a  Prolog  clause. 

X  The  clause  is  of  the  form  : 

X  nulK  FS  ) 

X  ehere  FS  is  the  feature  structure  associated  with  the  rule . 


X  this  is  an  epsilon  rule 

e_rule(  rule(Lhs,  □  ,Unifs) ,  OutStream  ) 

apply_rule_unifs(  Uhifs  ),  !,  X  unify  equations 
X  output  to  screen  if  trace  flag  is  on 
(  trace_rules(  yes  )  -> 

formate  'EPSILON  Rule  is  "B'n',  [  nulKLhs)  ]  ) 

1  true  ) . 

X  assert  into  the  database  for  use  during  compilation 
assert (  null(Lhs)  ),  !, 

X  output  to  file. deg 

vrite_clause(  (  nulKLhs)  ),  OutStream  ). 

X  error  -  cannot  compile  this  rule 
e_rule(  ruleCLhs ,  □  ,Unif s) ,  „OutStream  ) 

format(’"n***  Cannot  compile  rule:  "B”n',  [ruleCLhs  ,□  ,Unifs)])  . 

X  not  an  epsilon  rule 
e.ruleC  _Rule,  _OutStream  ). 
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7.  Module:  CDMPILEPATR.PL 
%  Submodule;  COHPXLEGRAMHAR.PL 
%  Author:  Susan  B.  Hirsh 

%  Purpose:  Perform  the  actual  compilation  of  the  grammar  entries. 


%  External  predicates  : 

•/. 

7. 

7.  Module  UMIFY.PL  - 
t 

7.  apply.  lex_unifB/5  - 

7a  apply  the  unification  equations  for  a  template  or  lexical 
%  entry. 

%  apply_rule_unif b/1  - 

7a  apply  the  unification  equations  for  a  grammar  or  lexical  rule. 

7. 

7a 

X  Module  PATRLIBIlARy.PL 

X 

I  clausify/3  - 

X  create  Prolog  clause  from  a  head  and  a  list  of  clauses. 

7a  reverse/3  - 
7.  reverse  a  list. 

X  Brite_clauBe/2  - 

X  srite  clause  to  output  stream  in  Prolog  cla\ise  format. 

X 

X 

X  Module  PATRSOPPORT.PL 
X 

X  find_category/2  - 

X  find  the  value  of  the  category  attribute  in  a  feature  structure. 
X  null/1  - 

X  precompiled  epsilon  rule. 


X - 

X 

X  compile_granmar(  Rules,  RuleList,  OutStream  ) 

X 

X  Input  : 

X  Rules  -  list  of  rules  to  be  made  into  DCG 

X  RuleList  -  list  of  rules  in  current  PATR-II  grammar 

X  OutStream  -  current  output  stream 

X 
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7. 

X  Take  each  PATR-II  rule  and  convert  it  into  a  DCG  rule. 


7.  no  Bore  rules  to  compile 

C0Bpile_ grammar (  [] ,  _RuleList,  _OutStream  ). 

7*  compile  each  rule 

compile_grammar(  [  Rule  I  Rules  ],  RuleList,  GutStream  ) 
7)  compile  the  rule 

compile.rule (  Rule,  RuleList,  GutStream  ), 

X  do  next  rule  . 

C0Dpile_grammar (  Rules,  RuleList,  OutStrean  ). 


X 

7,  coBpile_rule(  Rule,  RuleList,  OutStrecim  ) 

X 

X  Input  : 

X  Rule  -  current  PATR-II  rule 

7.  RuleList  -  list  of  all  rules  in  current  PATR-II  grammar 
7.  GutStream  -  current  output  stream 
X 
X 

X  Convert  each  PATR-II  rule  into  a  DCG  rule  or  a  Prolog  clause. 

X  Grammar  rules  become  DCG  rules  and  lexical  items  become 
X  directly  executable  Prolog  clauses  that  are  executed  shen 
X  compilation  is  completed,  resulting  in  full  lexical  entries. 

X  ignore  epsilon  rules,  because  they  sere  precompiled 
compile.rule  (  rule(  _Lhs,  □,  _Unifs  ),  _Rules,  _QutStream  ). 

X  error  -  parameter  statements  must  be  at  start  of  the  file 
compile.rule (  parameter(_Statement)  ,  _Rules,  .GutStream  ) 

format (’~n***  Parameter  statements  must  occur  at  start  of  grammar  filel'n’ ,  □ ) . 

X  handle  grammar  rules 

X  grammar  rules  are  compiled  into  DCG  rules  of  the  form  : 

X 

X  lc(  Rhsl,  Parent,  OldBranch,  NesBranch  )  — > 

X  dosnC  RhB2,  Branch2  ),...doBnC  RhsN,  BranchN  ), 

X  lc(  Lhs,  Parent,  Tree,  NesBranch  ). 

X 

X  shere: 
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X  Rhsl..Rh5N  -  element  of  the  right-hand  side  of  the  rule 
X  Parent  -  variable  associated  with  the  parent  of  the  rule 
X  OldBranch  -  parse  tree  so  far 

X  NewBranch  -  parse  tree  after  application  of  this  rule 
X  Branch2. .BranchB  -  parse  trees  for  each  node 
X  Tree  -  parse  tree  for  that  rule 
X 

coBpile_rule (  rule(  Lhs,  Rhs,  Unifs  ),  _Rules,  OutStream  ):- 
apply_rule_unifs(  Unifs  ),  X  unify  equations 

X  create  the  DCG  rule  for  the  initial  rule 
graiiiin2ur_rule  (  Lhs,  [  Hhs  ],  Put  Stream  ), 

X  return  new  list  of  rules  with  epsilon  expansions 
epsilon (  Rhs,  AllRhs  ), 

X  create  the  DCG  rule  for  the  grammar  rules 
grammar _rule (  Lhs,  AllRhs,  OutStream  ). 

X  handle  lexical  rules 

X  lexical  rules  eu:e  compiled  into  Prolog  clauses  of  the  form  : 

X 

X  lex_rule (  Name ,  InFS ,  OutFS  ) . 

X 

X  where: 

X  Name  -  name  of  this  lexical  rule 

X  InFS  -  input  feature  structure  to  this  rule  application 
X  OutFS  -  output  feature  structure  after  rule  application 

X 

compilc_rule (  lex_rule(  Name,  InFS,  OutFS,  Unifs  ),  _Biile8, 
_OutStream  );- 

apply_rule_unifs (  Ibifs  ),  X  unify  equations 

assert(  lex_rule(Name, InFS, OutFS)  ),  X  assert  into  database 

X  handle  lexical  entries 

X  lexical  entries  are  compiled  into  clauses  of  the  form: 

X 

X  word(  Name,  FS  )  — > 

X  applications  of  lexical  rules  and  templates  into 
X  FSI..FSN,  where  last  application  puts  result. 

X  into  FS . 

X 

coBpile_rule(  lex(  Word,  Unifs  ),  Rules,  _OutStrcam  ) 

X  unify  equations 

apply_lex_unifs(  Unifs,  Rules,  List,  HeadFS,  _FS  ), 

X  put  into  clause  form 

clausifyC  word(Vord,HeadFS) ,  List,  Clause  ), 
assert (  Clause  ) . 

X  handle  lexical  templates 
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'/.  lexical  templates  axe  compiled  into  clauses  of  the  form  : 

t 

X  template (  Name,  InFS,  OutFS  )  — > 

'L  applications  of  lexical  rules  and  templates  into 
V,  FS1.,FSN,  chere  last  application  puts  result 

Vt  into  OutFS. 

•/. 

coiipile_rule (  templateC  Name.  Unifs  ),  Rules,  .OutStream  ) 
unify  equations 

apply_lex_unifs(  Unifs,  Rules,  List,  OutFS,  InFS  ), 

7.  put  rule  into  clause  form 

clausifyC  template (Name, InFS, OutFS) ,  List,  Clause  ), 
assert (  Clause  ). 

7  rule  could  not  be  compiled  -  error 
conpile_rule (  Rule,  ^Rules,  _ Out Stream  ) 

formate ’"n***  Cannot  compile  rule:  "B'n'.CRulej). 


7 

7,  grammar _rule  (  Uis,  Rhs,  OutStream  ) 

1 

7.  Input  •- 

7,  I.bfl  -  left-hand  side  of  the  rule 
%  Hhs  -  edl  possible  right-hand  sides  for  this  rule 
OutStream  -  current  output  stream 
X 
% 

1  Take  each  possible  Rhs  for  the  rule  and  create  a  DCG  rule  for 
X  it. 


X  make  a  DCG  from  each  Rhs 

grammar _rule (IJis ,  [  [  Rhsl  I  RhsH  ]  |  KoreRhs  ], OutStream)  :- 
X  create  right-hand  side 

rhsC  Lhs,  RhsN,  Parent,  □,  Clauses,  Branch,  NesBranch) , 
start.symboK  Lhs,  OutStream  ),  X  find  grammar  start  symbol 

7.  output  nes  DCG  rules  to  the  screen  if  trace  flag  is  set 
(  trace_rule8(  yes  )  -> 
format(  ’GRAMMAR  RULE  is  "B"n’, 

[(lc(Rhsl, Parent, Branch, NesBranch)  — >  Clauses)]) 

I  true  ) , 

X  output  nes  DCG  rule  to  file. deg 

write^clauseC  (Ic (Rhsl, Parent, Branch, NesBranch) — >Clauses)  , 
OutStream  ) , 
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X  go  to  next  right-hand  side 

grammar _rule  (  T.hs ,  HoreRha ,  DutStream  )  . 

X  no  more  right-hand  sides  to  iii2tke  rules  from 
grammar.rule (  _Lhs,  □,  _DutStream  ). 


X - 

X 

X  rhs(  I.hs,  Rhs,  Parent,  Branch,  List,  OldBreuich,  NeeBranch  } 

X 

X  Input  : 

X  I.hs  -  left  heind  side  of  the  rule 

X  Rhs  -  All  but  first  of  right-hand  side  of  the  rule 
X  Parent  -  parent  of  this  rule 

X  OldBranch  -  branch  variable  for  the  left-hand  side  of  the  rule 

X  HeoBranch  -  branch  variable  for  the  left-hand  side  of  the  rule 

X 

X  Output  : 

X  List  -  list  of  Rhs  elements  in  the  form  for  an  LC  rule 

X  Branches  -  list  of  branches  as  variables  in  the  parse  tree 

X 

X 

X  Create  the  clauses  for  the  right-hand  side  of  the  DCG  rule 


X  keep  track  of  branches  and  build  up  right-hand  side 
rhsC  Lhs,  [  Rhsl  I  Rhs  ],  Parent,  Branches,  (dovnCRhsl, Branch)  ,NevRhs) , 
OldBranch,  NevBranch  )  :- 

rhs(  Lhs,  Rhs,  Parent,  [  Branch  I  Branches  ],  NevRhs,  OldBranch, 
NevBranch  ) . 

X  no  more  branches,  create  left-hand  side 

rhs(  Lhs,  □,  Parent,  Branches,  Ic (I.hs ,  Parent,  Tree,  NevBranch), 
OldBranch,  NevBranch  )  :- 
X  get  category  for  parse  tree 
f ind_category (  Lhs,  Cat  ), 

X  put  constituents  in  proper  order  for  tree 
reverse (  Branches,  □,  Constituents  ), 

X  put  into  form  CatCOldBranch, Constituents) 

Tree  =. .[Catl [OldBranch I  Constituents]] . 


X- 

X 
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'!•  epsilonC  Rule,  Neorules  ) 

7. 

7.  Input  : 

X  Rule  -  current  rule 

7. 

7.  Output  : 

7.  Neorule  -  a  list  of  all  possible  right-hand  sides  for  this 
7.  rule 

7. 

7. 

7«  As  long  as  the  first  element  of  the  right-hand  side  of  the  rule 
X  can  be  expanded  by  an  epsilon  rule,  return  the  rule  minus  that 
X  element . 

X 

X  For  example  : 

X  The  rules  S  ->  NP  VP 

X  HP  ->  e 

X 

X  Vill  produce  the  list  [  VP  ] ,  since  the  NP  can  be  expanded  by 
X  the  epsilon  rule.  When  returned,  there  are  understood 
7.  to  be  too  rules  noo  instead  of  the  one.  The  rules  are: 

X 

7.  S  ->  NP  VP 

X  S  ->  VP 


X  check  the  first  element  of  the  right-hand  side 
epsilon(  [  Rhsl  I  Rhs  ],  [  Rbs  ]  NeoRhs  ])  :- 

nulK  lihsl  ),  !,  X  can  be  expanded  by  an  epsilon  rule 

epsilonC  Rhs,  NeoRhs  ).  X  check  if  next  can  be 

X  no  more  nonterminals  can  be  expanded  by  epsilon  rule 
epsilonC  _Rhs,  □  ). 


X  start.symbolC  Lhs,  OutStream  ) 

X 

X  Input  : 

X  t.hs  -  left-hand  side  of  the  rule 
X  DutStream  -  current  output  stream 

X 

7. 

X  If  no  start  symbol  for  the  grammar  has  been  specified,  it  is 
X  the  nonterminal  on  the  left-hand  side  of  the  first  rule. 
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%  start  symbol  is  already  specified 
start_symbol(  _I.hs ,  _QutStreaBi  ) 

start (  _Cat  ),  !.  7.  start  symbol  is  in  database 

no  start  symbol,  need  to  add  one 
start_symbol(  Lbs,  OutStreaa  ) 

find_category  (  Lhs,  Cat  ),  7.  get  Cat  of  start  symbol 

assertC  start  (Cat)  ),  %  zissert  as  start  symbol 

7.  start  symbol  is  needed  in  pearsing,  so  output  it  to  peorser  file 
write_clausc(  (  start (Cat)  )  ,  OutStream  ). 
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y.  Module:  COHPILEPATR.PL 
%  Submodule:  UNIFY. PL 
%  Author:  Susan  B.  Hixsh 

'U  Purpose:  Apply  the  unification  equations  constraining  a  rule. 

%  External  predicates  : 

•/. 

■/. 

%  Module  PATRSUPPORT.pl 

X 

X  thepath/4  - 

X  extract  the  value  for  a  particular  feature  from  a  feature  structure. 


X- 


V.  apply_rule_unifs(  Unifs  ) 

X 


X  Input  : 

X  Unifs  -  list  of  unifications  for  the  rule 

X 

X 


X  Unify  the  values  in  each  equation  in  a  grammar  or  lexical  rule. 


X  handle  unifications  of  the  form  :  Pathl  =  Path2 
X  E.G.. 

X  <S  head>  ■=  <VP  head> 
apply_rule_unif b(  [  [  Vari  I  Featuresl  ]= 

[  Var2  I  FeatureB2  ]  I  T  ]  )  .— 

X  find  paths  from  these  features  and  unify  values 
find_path(  main,  Featuresl,  Val,  Varl  ), 
find_path(  main,  Features2,  Val,  Var2), 
apply_rule_unifsC  T  ) . 

X  handle  unifications  of  the  form  :  Path  val 
X  E.G., 

X  <X  cat>  =  np 

apply_rule_unif s (  [  [  Var  I  Features  ]=Atom  |  T  ]  );- 
atomic(  Atom  ) , 

X  find  location  of  this  feature 
find_path(  main.  Features,  Atom,  Var  ), 
applyjnile_unifs(  T  ) . 
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no  sore  unification  equations 
apply_rule_ujiif  s(  □  )  . 


y,  apply_lex_unifa(  Unifs,  Rules,  List,  KeadFS,  FS  ) 

•/. 

y,  Input  ; 

y,  Unifs  -  list  of  unifications  for  the  rule 
y.  Rules  -  list  of  rule  in  the  grammar 

’/ 

y  Output  : 

y.  List  -  list  of  rules  to  assert 

y,  HeadFS  -  feature  structure  for  head  of  clause 

y,  FS  -  initial  input  feature  structure 

y. 

y. 

y.  Unify  the  values  in  each  equation  in  a  lexical  entry  or  template. 


y,  no  more  unifications  to  do 

_Rules,  □,  FS,  FS  ) . 

y  handle  unifications  of  the  form  :  Path  ==  val 
y  E.G.. 
y.  <X  cat>  =  np 

apply_lei_unif 3 (  [  Features=Atom  IT],  Rules,  List,  HeadFS, 
FS 

atomic (  Atom  ) , ! , 
y  get  position  of  this  feature 
find_path(  main.  Features,  Atom,  FS  ), 
apply_ler_unif s (  T,  Rules,  List,  HeadFS,  FS  ). 

y,  add  application  of  a  lexical  template  to  the  nes  DCG  rule 
apply_lei_unifs(  [  Atom  IT],  Rules, 

[  template{Atom,FS,TempFS)  I  List  ], 

HeadFS,  FS  )  :- 
atomic (  Atom  ), 

y,  make  sure  this  is  a  template 
find_type(  Atom,  Rules,  template  ),!, 
apply_lex_unifs(  T,  Rules,  List,  HeadFS,  TempFS  ). 

y.  add  application  of  a  lexical  rule  to  the  nen  DCG  rule 
apply _lex_uniis(  [  Atom  IT],  Rules, 

[  lex_rule (Atom, FS, TempFS)  1  List  ], 
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HeadFS,  FS) 
atomic C  Atom  ) , 

apply_lex_\mifs(  T,  Rules,  List,  HeadFS ,  TempFS  ). 

'L  handle  unifications  of  the  form  ;  Fathl  -  Path2 
•/.  E.G.. 

%  <head>  =  <head> 

apply_lex_unif 3 (  [  Featuresl=Features2  IT],  Rules,  List,  HeadFS, 
FS) 

find_path(  main,  Featuresl,  Val,  FS  ) , 
find_path(  main,  Features2,  Val,  FS  ), 
apply _lex_unifs(  T,  Rules,  List,  HeadFS,  FS  ) . 


X 

7.  find_path(  PrevFeature,  Features,  Value,  Vax  ) 

7. 

7,  Input  : 

7,  PrevFeature  -  previous  feature  in  the  path 
7,  Features  -  list  of  features  in  this  equation 
7,  Value  -  postion  of  feature  in  feature  structure 
7,  Var  -  feature  structure  unifications  are  acting  on 

7. 

7. 

7.  Folloe  a  path  of  features  and  return  the  value  at  the  end. 


7.  do  for  each  feature  in  list 
find_path(  Place,  [  Head  |  Rest  ]  ,  Atom,  Var  ) 
7.  search  in  path  information 
thepathC  Place,  Head,  Var,  Path  ), 
find_path(  Head,  Rest,  Atom,  Path  ). 

7.  stop  at  end  of  feature  list 
find_path(  _Place,  □,  Atom,  Atom  ), 


•i 

7.  find_type(  Atom,  Rule,  Type  ) 

7. 

7i  Input  : 

7.  Atom  -  name  of  current  template  or  lexical  rule 
7.  Rule  -  top  vadue  on  rule  list 
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•/. 


X  Output  ; 

%  Type  -  teoplate  or  rule,  depending  on  type  oi  rule 

•/. 

•/. 

X  Return  vbether  a  lexical  item  is  a  template  or  lexical  rule. 


X  lexiced  template 

find_type(  Atom,  [  template(Atom,_Xbiifs)  I  _Tail  ]  , 
template  ) 

X  lexical  rule 

find_type(  Atom,  [  lei_rule(Atom,_lnFS,_QutFS,_Uniis)  I  _Tail  ], 
rule  )  . 

X  keep  searching 

find_type(  Atom,  [  _Head  I  Tail  ],  Tyi>e  ) 
fiiid_type(  Atom,  Tail,  Type  ). 
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X  Module:  CQMPILEPATR.PL 
X  Submodule :  COHPILELEX .PL 
X  Author:  Susan  B.  Hirsh 
X  Purpose:  Compile  all  lexical  entries. 


X  External  predicates  : 

X 

X 

X  Module  PATRLIBRARY.pl 
X 

X  write_clause/2  - 

X  vrite  clause  to  output  stream  in  Prolog  clause  format. 

X 

X 

X  Module  PATRSUPPORT.pl 
X 

X  Bord/2  - 

X  lexical  entry  from  the  database. 


X  conpile_lex(  OutStream  ) 

X 

X  Input  : 

X  OutStream  •-  current  output  stream 

X 

X 

X  Precompile  each  lexical  entry.  This  involTes  actueilly 
X  executing  each  one  and  then  outputting  the  nev  entry  as 
X  lex<  Word,  FS  ). 


X  execute  the  lexical  entry  and  output  it 
compile_lex(  OutStream  ) 

Bord(  Word,  FS  ) ,  X  execute  lexical  entry 

X  output  to  screen  if  trace  flag  is  set 
(  trace_rule3{  yes  )  -> 

format(  'LEXICAL  ENTRY  is  C  (lex(Word,FS)  )  ]  ) 

I  true  ), 

X  write  lexical  entry  to  output  file 
Brite_clau3e{  (  lex{Word,FS)  ),  OutStream  ), 
fail.  X  go  to  next  lexical  entry 
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y,  no  BOre  lexical  entries 
C0Bpile_lex(  _OutStreaB  ). 


■/.  Module:  PATRSUPPORT.PL 
y.  Author:  Susan  B.  Hirsh 
y.  Purpose:  Support  nodule  for  the  parser. 


y.  Predicates  necessary  at  runtime  : 

'L 

y. 

'L  LC  Parser  - 

y. 

y.  patr/O  - 

input  loop  using  start  symbol, 
y.  parse/2  - 

y  get  all  parses  for  a  sentence 
y,  print_parse8/2  - 

y  print  parses  and  parse  trees  for  a  sentence, 
y.  misc.  LC  predicates  ~  parse/2,  doBn/2,  lc/4,  and  leaf/2 

y. 

y. 

y  Utility  predicates  - 

y. 

%  alphanuneric/l  - 
y  character  is  2dphanumeric. 
y  append/3- 

y  concatenate  two  lists, 
y  case_shift/2  - 

y  convert  a  list  to  lover  case, 
y  concat/3  - 

y  concatenate  tvo  atoms, 
y  digit/1  - 

y  character  is  a  digit, 
y  end_file/l  - 
y  end  of  file  character, 
y  f ind_category/2  - 

y  find  value  of  category  attribute  in  a  feature  structure, 
y  loraat_stats/0  - 
y  print  runtime  statistics, 
y  full_8top/l  - 

y 

y  nember/2  - 

y  check  membership  in  a  list, 
y  nev.line/l  - 
y  nev-line  character, 
y  string_size/2  - 
y  get  length  of  an  atom, 
y  8et_timer/0  - 
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set  runtime  timer. 

X  thepath/4  - 

X  return  the  value  of  a  path. 
X  upper/ 1  - 

X  character  is  upper  case. 


X  set  up  the  system  : 


X  declare  type  of  predicates 

dynamic (null/ 1) .  X  epsilon  rules 

dynamic (start/1) .  X  start  symbol 

dynamic  (feature_order/3)  .  X  path  information 

X  operator  definition 
op(500,zf X, : ) . 


X  LC  rules  appear  in  too  files 
multifile  lc/6. 


no_style_chec>:(  all  ) .  X  suppress  samings 


ensure_loaded(  pp  ).  X  load  prettyprinter 

ensure_loaded(  readin  ) .  X  load  sentence  reader 


X  predicates  necessary  for  the  LC  parser  to  run 


X  initial  calling  sequence 

parse (  Cat ,  Tree  )  -->  doyn(  Cat ,  Tree  ) . 


X  pick  up  a  nee 

X  epsilon  rules 
dora(  Cat,  □  ) 

X  get  next  sord 


left  corner  vhen  one  has  been  processed 

{  nulK  Cat  )  }. 

and  find  ehose  left  comer  it  is 
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dofm(  Cat,  Tree  )  — > 

leai (  Child ,  OldTree  ) , 

le(  Child,  Cat,  OldTree,  Tree  ). 


X  every  phrase  is  the  left  comer  of  itself 
lc(  Type,  Type,  Tree,  Tree  )  — >  Q. 


’!,  this  is  a  vord 

X  get  the  category  information  for  parse  tree 
leaf(  FS,  Tree  )  — >  X  handle  lexical  entries 

E  Word  3 ,  X  get  the  word 

{  lex(  Word,  FS  )  },  X  get  oord’s  feature  structure 

{  f ind_category(  FS,  Cat  )  >,  X  get  category  of  feature  structure 

{  Tree  .  ECat.Word]  X  naie  parse  tree 


X 

X  patr 

X 

X 

X  Read  in  a  sentence  and  p2tr8e  it  sith  the  start  symbol.  By  starting 
X  the  parse  vith  a  feature  structure  sith  the  'cat'  feature 
X  specified  as  the  start  symbol,  the  only  good  parses  are  those 
X  that  result  in  a  parse  shose  'cat'  feature  is  that  start  S3rmbol. 


patr  ; - 

read.inC  Sentence  ) , 
start  (  Symbol  ), 
find_category(  S,  Symbol  ), 
parse (  S ,  Sentence  ) . 


X  read  in  the  sentence 
X  get  the  start  symbol 
X  create  filter  for  sentence  parse 
X  parse  the  sentence 


X - 

X 

X  parse (  Structure,  Sentence  ) 

X 

X  Input  : 

X  structure  -  feature  structure  ehose  structure  the  parse  must 
X  match 
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*L  Sentence  -  sentence  to  paurse 

% 

% 

%  Get  all  parses  for  a  sentence  and  print  them  out.  Read  in  a 
%  nes  sentence  and  parse  it. 


%  no  more  sentences 
parseC  S,  end_of_file  ):-  !. 

%  p^se  sentences 
parseC  S,  □  )  , 

read_in(  ResSentence  ) , 
parse(  S,  NesSentence  ). 

parseC  S,  Sentence  ) 

set_tiner,  */,  set  runtime  timer 

%  get  all  parses  and  p2trse  trees  for  a  sentence 
bagofC  S-Tree,  parse  (S, Tree,  Sentence,  □) ,  Parses  ),!, 
forHat_stats,  X  print  runtime  statistics 

print  .parses  (  Parses,  0  ),  X  print  p2irses 
read.inC  HesSentence  ),  X  read  in  a  nes  sentence 
parseC  S,  NesSentence  ).  X  pckrse  that  sentence 

X  error  -  couldn’t  parse 
parseC  S,  HoParse  ) 

foiaat.Btats,  X  print  runtime  statistics 

X  print  error  message 

formatC’“n»»*  Cannot  parse  "B"n',[NoParse3), 
read.inC  NenSentence  ) ,  X  read  a  nee  sentence 
parseC  S,  NesSentence  ).  X  parse  that  sentence 


X 

X  print.parsesC  Parses,  NumParses  ) 

X 

X  Input  ; 

X  Parses  -  list  of  parses  and  parse  trees  for  a  given  sentence 
X  HumParses  -  number  of  parses  for  the  sentence 

X 

X 

X  Print  the  parses  and  parse  trees  for  a  sentence. 


X  print  analysis  on  each  parse 
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print_par3e3(  [  Parse-Tree  1  Parses  ],  Count  ) 

%  increment  count  of  nunber  of  parses 
NenCount  is  Count  t  1, 

7.  print  analysis 

format (’~nAnalysis  #  "d:"n"nPar3e  Tree  =  "w"n' , [HesCount.Tree]) 
f  ormat ( ’ "p"n ’ , [Parse] ) , 

print _par3es (  Parses,  NesCount  ).  X  next  parse 

X  no  more  parses 
print_parBes(  [] ,  Count  ) 

7.  print  count  of  number  of  parses 

format ('"nSuaber  of  Parses  =  “d“n [Count] ) . 


X - 

7. 

X  concat (  Atonl,  Atom2,  Atom  ) 

X 

X  Input  : 

7.  Atoml  -  first  atom 
X  Atom2  -  second  atom 

X 

X  Output  : 

X  Atom  -  concatenation  of  Atoml  and  Atom2 

X 

X 

X  Concatenate  tvo  atoms. 


concat (  Atoml,  Atom2,  Result  ) 
name(  Atoml,  Listl  ), 
name(  Atom2,  List2  ) , 
appendC  Listl.  Li8t2,  Lists  ), 
name (  Result ,  Lists  ) . 


X  put  in  list  form 
X  put  in  list  form 
X  concatenate  as  lists 
X  make  into  an  atom 


X - 

X 

X  appendC  Listl,  List2,  List  ) 
X 

X  Input  : 

X  Listl  -  first  list 
X  List2  -  second  list 

X 

X  Output  : 
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*/.  List  -  concatenation  ol  Listl  end  List2 

X 

X 

X  Concatenate  teo  lists. 


X  a  list  appended  to  the  empty  list  is  that  list 
appendC  □,  List,  List  ). 

X  a  list  appended  to  another  adds  the  head  to  a  nev  list 
appendC  [  Head  |  Listl  3,  Li3t2,  [  Head  I  List3  ]  )  :- 
appendC  Listl,  List2,  Lists  ). 


X 

X  f ind_categoryC  FS,  Cat  ) 

X 

X  Input  : 

X  FS  -  a  feature  structure  to  get  the  category  value  from 

X 

X  Output  : 

X  Cat  -  category  value  of  the  feature  structure 

X 

X 

X  Get  the  value  of  the  category  attribute  in  the  FS. 
find_category(  Lhs,  Cat  ) 

thepathC  main,  cat,  Lhs,  Cat  ),  X  get  category  of  nonterminal 
atomicC  Cat  )  ,  ! . 

X  if  Cat  value  isn’t  an  atom,  make  it  X 
find.categoryC  Lhs,  x  ). 


X 

X  member C  Element,  List  ) 

X 

X  Input  ; 

X  Element  -  element  to  check  membership  of 
X  List  -  list  to  check  membership  in 
X 
X 

X  Check  nhethex  an  element  is  a  member  of  a  list. 
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'L  element  is  head  of  the  other  list 
nenherC  Element,  [  Element  I  _Rest  ]  )  !. 

'U  keep  se2a:ching  the  list 
member (  Element,  [  _Head  I  Rest  ]  )  :- 
member (  Element,  Rest  ). 


\ 

X  set_timer 

X 

X 

X  Reset  runtime  timer. 

Bet_tiner 

statisticsC  runtime,  [  ..RunTime  ]  ). 


X  format_stat8 

X 

X 


X  Print  runtime  information 


format_stats 

statisticsC  runtime,  [  Stats  ]  ), 

Time  is  Stats/lOOO, 

formate  ’“nRuntime  =  “fn’,  C  Time  ] 


X  get  runtime 
X  convert  to  seconds 
X  print  rrmtime. 


X 

X  string_size(  Atom,  Size  ) 

X 

X  Input  : 

X  Atom  -  atom  to  get  length  of 

X 

X  Output  : 

X  Size  -  number  of  characters  in  the  atom 
X 
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1. 

'L  Get  the  number  of  characters  in  an  atom. 

string_size(  String.  Size  ) 

neuneC  String,  List  ),  %  maice  into  a  list 

lengthC  List,  Size  ).  %  get  the  length  of  the  list 


X - 

■/. 

y,  thepathC  Node,  Label,  Term,  Value  ) 

1. 

Input  ; 

'L  Node  -  start  feature 
X  Label  -  current  feature 

•/. 

7,  Output  : 

X  Term  -  feature  structure 
X  Value  -  value  of  Label  attribute 

X 

X 

X  Return  of  the  value  of  the  path  <Node,Label>. 


thepathC  Node,  Label,  Term,  Value  ) 

X  get  the  structure  of  the  FS 
feature_order(  Node,  FS,  Term  ), 

membexC  Label rValue,  FS  ) .  X  get  the  value 


i 

X  case_shift(  Token,  NevToken  ) 

X 

X  Input  : 

X  Token  -  current  input  token 
X 

X  Output  ; 

X  NevToken  -  Token  in  all  lover  case. 

X 

X 

X  Convert  token  to  all  lover  case. 
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‘/,  if  upper  case,  convert  to  lover 
case_shif t (  [Upper  I  Mired  3 ,  [  Letter  I  Lover  ] ) 
upper (  Upper  ) ,  ! , 

Letter  is  X^per-)-32,  */,  sale  lover  case 

caae_8hiit{  Mixed,  Lover  ). 

'L  if  not  upper  case,  ignore 

case_shift(  [  Other  I  Mixed  3,  [  Other  I  Lover  ]) 
case_shift(  Mixed,  Lover  ). 

no  more  to  lover  case 
case_shift(  □,  Q  ). 


%■ 

% 

7. 

X 


alpha_nuDeric (  Char  ) 


X  Input  : 

X  Char  -  character  to  check 

X 

X 

X  Check  vhether  a  character  is  alphanumeric. 


alpha_numeric (Ch) 


upper (  Ch 

) 

X 

A..Z 

Ch  >=  97, 

Ch  =<  122 

X 

a.  .z 

digit (  Ch 

) 

X 

0..9 

Ch  =  95 

X 

>  ) 

Ch  =  63 

X 

Ch  =  42 

X 

'*> 

Ch  =  39 

X 

nonstandard 

Ch  =  96 

X 

nonstandard 

X  digit (  Char  ) 

X 

X  Input  : 

X  Char  -  character  to  check 

X 

X 
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7,  Check  ohether  a  character  is  a  digit. 


digitC  Ch  )  7.  0..9 

(  Ch  >=  48 
,  Ch  =<  57 
). 


7. 

7.  upper  (  Char  ) 

7. 

7.  Input  : 

7.  Char  -  character  to  check 


7. 

1. 

7  Check  Bhether  a  character  is  an  upper  case  letter. 


;q)per(  Ch  )  %  A..Z 

(  Ch  >=  65 
,  Ch  =<  90 
). 


input  delimiters 


iull_stop(  46  ) 
end_file(  -1  ) , 
neB_linc(  10  ) . 


7.  ’ . ' 

%  end  of  file 
%  neB  line 
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